Sichere Integration von Web Services

Quelle: Netzguide E-Security 2006
Autor: Tom Hager, CEO, InfoTrust

Web Services werden zur Verbindung unterschiedlicher Systemwelten eingesetzt. Die Verbindung von Applikationen ist dabei nicht unproblematisch. Web Services müssen sowohl auf der Basis der Infrastruktur wie auf der Applikationsebene geschützt werden.

Das Internet zur Unterstützung der Geschäftsprozesse ist in vielen Unternehmen nicht mehr wegzudenken. Neben E-Mail ist der Webzugriff über den Browser die meist benutzte Anwendung rund um das Internet. Beim klassischen Webzugriff baut der Benutzer über den Webbrowser eine Verbindung zu einem Webserver auf. Die Interaktion findet gewissermassen zwischen Mensch und
Applikation statt. Ein anderer Ansatz wird beim Einsatz von Web Services verfolgt. Hier findet die Interaktion zwischen den Applikationen statt (Abbildung 1). Der folgende Beitrag diskutiert Aspekte, die bei der Integration von Web Services aus sicherheitstechnischer Sicht zwingend beachtet werden müssen.

Abb. 1: Beim klassischen Webzugriff baut der Benutzer über den Webbrowser eine Verbindung zu einem Webserver auf. Bei den Web Services findet die Interaktion zwischen den Applikationen statt.

Per Definition wird unter Web Services ein Dienst verstanden, der über das Internet zur Verfügung gestellt wird und mittels standardisierten XML-Meldungen kommuniziert, unabhängig vom Betriebssystem und von der Programmiersprache. Mit Hilfe von Web Services können Applikationen untereinander kommunizieren. Es wird unterschieden zwischen Service Provider (stellt einen Service zur Verfügung), Service Requestor («Anwender», die Applikation baut die Netzwerkverbindung auf und sendet eine XML-Anfrage zum Service Provider) und Service Registry (zentrales Verzeichnis der verfügbaren Web Services).

Für den Austausch der XML-Meldungen stehen unter anderem die Formate SOAP und XML-RPC zur Verfügung. Das Simple Object Access Protocol (SOAP) ist heute der Standard für Web Services. SOAP nutzt als Kommunikationsprotokoll HTTP, unterstützt aber auch Protokolle wie SMTP, FTP oder BEEP (Abbildung 2).

Abb. 2: Im erweiterten Web Service Stack befinden sich die Protokolle UDDI, WSDL und SOAP. SOAP ist heute der Standard für den Austausch von XML-Meldungen.

Eine SOAP-Meldung besteht aus zwei Teilen, einem Header und einem Body, der die Methoden enthält (beispielsweise einen Programm-Aufruf, der die Preise aktualisiert). Damit ein Web Service automatisiert angewendet werden kann, ist seine Beschreibung mittels WSDL (Web Service Description Language) standardisiert. Web Services können mit Hilfe des UDDI-(Universal Description, Discovery and Integration)Protokolls über ein zentrales Verzeichnis angeboten werden.

In der Praxis werden Web Services zur Verbindung von unterschiedlichen Systemwelten eingesetzt. Dies ist der Fall bei ERP- und CRM-Applikationen, die mit Web-basierendem Front-End betrieben werden, deren Business-Logik aber auf klassischen Host-Systemen läuft. Web Services werden beispielsweise auch bei Finanzdiensten (SWIFT), bei der elektronischen Rechnungsstellung, beim Supply Chain Management, zum Versenden von Fax-Nachrichten und bei Webshops sowie Suchmaschinen eingesetzt. Der CRM Service-Anbieter Salesforce.com synchronisiert über einen eigenen Web Service die Daten aus den Outlook-Mailboxen der Benutzer mit der zentralen Datenbank. Es gibt heute sehr viele Anbieter von Web Services, die vielfach nur von einer klar definierten (privaten) Gruppe von Anwendern benutzt werden können. Die Zahl öffentlich angebotener Web Services nimmt aber sehr schnell zu.

Fehlerbehandlung über XML-Meldungen

Bei der nachfolgenden Betrachtung der Sicherheitsaspekte von Web Services muss zwischen der Sicherheit in der Infrastruktur und der Sicherheit auf Applikationsebene unterschieden werden. Auf der Seite der Infrastruktur gelten generell beim Einsatz von Web Services dieselben Sicherheitsüberlegungen wie bei «normalen» Web-Applikationen: Der anfragende Benutzer beziehungsweise die Applikation muss sich vor dem Zugriff sicher authentisieren, der HTTP-Verkehr soll mit SSL verschlüsselt werden und die Systeme müssen mit geeigneten Massnahmen (Intrusion Prevention) vor Denial-of-Service-Angriffen geschützt werden. Diese Sicherheitsmassnahmen lassen sich sehr einfach mit einem Web Application Security Gateway realisieren. Dieser Gateway arbeitet auf der Applikationsebene und überprüft die XML-Meldungen auf ihre Korrektheit (Abbildung 3).

Abb. 3: Der Web Application Security Gateway arbeitet auf der Applikationsebene und überprüft die XML-Meldungen auf ihre Korrektheit.

Die Verbindung von Applikationen mittels Web Services ist nicht unproblematisch. Mangelhaft programmierte SOAP-Methoden können zu Fehlverhalten in der Applikation oder gar zum Absturz der Applikation führen. Bewusst ausgenutzt kann solches Verhalten für einen Angriff auf die Web-Applikation mit dem Ziel des Zugriffs auf Unternehmensdaten verwendet werden. Bei der Integration von Web Services muss daher klar definiert werden, welche SOAP-Methoden zugelassen werden sollen und welche Rückgabewerte von den Applikationen erwartet werden. Auch hier kann mit Hilfe eines Web Application Security Gateways ein entsprechendes Filtering realisiert werden. Ein weiterer Punkt ist, dass vermieden werden muss, dass durch ungewollte Fehlermeldungen (zum Beispiel Datenbank-Error) einem potentiellen Angreifer zu viele Informationen über die Infrastruktur
mitgeteilt werden, etwa über eingesetzte Produkte oder Produktversionen. Dies lässt sich durch die Unterdrückung oder die Filterung von Fehlermeldungen vermeiden. Die Fehlerbehandlung muss
in der Applikation über klar definierte XML-Meldungen (SOAP-Methoden) erfolgen.

Sichere End-to-end-Kommunikation

Neben dem Schutz der Web Services auf der Basis der Infrastruktur muss der Schutz auf Applikationsebene gewährleistet werden. Diesem Thema muss sich der Web Service Provider während der Design-Phase widmen. Für die Absicherung der Web Services auf Applikationsebene existieren Sicherheitsstandards und Erweiterungen zum Standard. Das internationale Konsortium OASIS (Organization for the Advancement of Structured Information Standards, www.oasis-open.org)
befasst sich unter anderem mit den Sicherheitsaspekten von Web Services.

Die Vorteile der Schutzmassnahmen auf Applikationsebene liegen bei der Unabhängigkeit von den Kommunikationsprotokollen (HTTP, HTTPS, SMTP, FTP, usw.) und der Infrastruktur. Die XML-Meldungen selbst werden gesichert und dann übertragen. So wird die Übertragung einer sicheren Meldung über einen unsicheren Übertragungskanal ermöglicht (sichere End-to-end-Kommunikation).

Die Web-Service-Standards erlauben die Signierung und die Verschlüsselung der XML-Meldungen.
Die XML-Signatur kann auf einen Teil oder auf das ganze XML-Dokument angewendet werden. Innerhalb der SOAP Envelope wird im SOAP Header definiert, welche Daten im SOAP Body signiert werden (Abbildung 4).

Abb. 4: Die Web-Service-Standards erlauben die Signierung und die Verschlüsselung der XML-Meldungen. Die XML-Signatur kann auf einen Teil oder auf das ganze XML-Dokument angewendet
werden. Innerhalb der SOAP Envelope wird im SOAP Header definiert, welche Daten im SOAP
Body signiert werden.

Die Sicherheitserweiterung von SOAP ist im WS-Security Standard von OASIS definiert. Durch diesen kann der Absender einer XML-Meldung klar identifiziert werden. Der Standard sieht die Verwendung von X509.v3-Zertifikaten vor. Die Verschlüsselung der XML-Meldungen kann einzeln oder in Kombination mit der Signierung eingesetzt werden und erlaubt die Verschlüsselung von einzelnen Werten oder ganzen Meldungen. Mit dem in WS-Security definierten Message Timestamp erhält eine SOAP-Meldung einen verbindlichen Eintrag der Zeit ihrer Erstellung und der Dauer ihrer Gültigkeit.

Web Services können über verschiedene Applikationen oder Organisationen verteilt sein. Ein Benutzer möchte zum Beispiel über ein Reiseportal ein Komplettpaket buchen. Das Reiseportal ist über Web Services mit den Applikationen der Fluggesellschaft, dem Hotelanbieter und der Mietwagen-Firma verbunden. Zur Buchung des Komplettpakets muss sich der Benutzer am Reiseportal authentisieren. Damit sich der Benutzer nicht auch bei den anderen drei Web-Applikationen authentisieren muss, kommt SAML (Security Assertion Markup Language) zum Einsatz. SAML erlaubt die Realisierung eines Single-Sign-On-Konzepts über mehrere Applikationen.

Ein Nachteil von Sicherheitsmassnahmen auf Applikationsebene ist allerdings, dass durch die verschiedenen zusätzlichen Sicherheitseinträge die XML-Meldungen grösser werden. Dies bedeutet, dass mehr Bandbreite benötigt wird. Auch die Verarbeitung auf den Web-Applikationsservern ist CPU-intensiver und dauert daher länger.

Fazit

Web Services können sicher eingesetzt werden, wenn klare Sicherheitsrichtlinien eingehalten und Schutzmassnahmen implementiert werden. Grosser Wert muss auf den Einsatz von Schutzmassnahmen auf Applikationsebene gelegt werden. Der Schutz der Infrastruktur ist dadurch aber keineswegs zu vernachlässigen.

top