Zugegeben, die Idee ist verlockend, dass sich verteilte Anwendungen über einfache Web-Server-Aufrufe via Internet kombinieren lassen. Doch bei jeder Kommunikation über öffentliche und unsichere Netze darf das Thema Sicherheit nicht außen vor bleiben. So verwundert es kaum, dass in einer von Cap Gemini durchgeführten Studie 60 Prozent der Befragten Sicherheitslücken befürchten. Dass die Sorgen nicht unbegründet sind, bestätigt Ray Wagner, Forschungschef bei Gartner Research. Er weist darauf hin, dass bei Web-Services nach wie vor ungelöste Sicherheitsprobleme bestehen.

Daran können selbst die von Microsoft, IBM und Verisign entwickelten Spezifikationen zur Web-Services-Security (WS-Security) wenig ändern. Sie liegen mittlerweile dem Standardisierungsgremium Organization for the Advancement of Structured Information Standards (Oasis) vor und wurden auch von Sun als unterstützenswert befunden. Ein Zeichen, dass sich die Industrie wohl tatsächlich wichtige Impulse von der neuen Technologie erhofft. Allerdings handelt es sich bei den Sicherheitsspezifikationen um erste Ansätze, die noch weit von einer praxistauglichen Lösung entfernt sind.

Eines der Kernprobleme der neuen Technologie ist, dass die Web-Services beziehungsweise deren XML-basierendes Nachrichtenformat Simple Open Access Protocol (Soap) HTTP als Transportprotokoll benutzen. Die RPC-Aufrufe werden dabei ohne Kennzeichnung der ausführbaren Inhalte in XML gekapselt und über HTTP (auch SMTP wäre möglich) übertragen. Damit tun sich die gleichen Probleme auf, unter denen auch die bisher gängigen Web-Anwendungen leiden: Firewalls bieten keinen vollkommenen Schutz gegen Angriffe. Die gängigen Firewallsysteme - in der Regel Paketfilter - können nur beurteilen, ob es sich um einen rechtmäßigen HTTP-Verkehr handelt, also der dazugehörige Port 80 adressiert wird. Firewalls kennen zudem nur einen unidirektionalen Datenverkehr, das heißt, es wird nicht geprüft, ob einem Datenpaket, das von innen an einen externen Empfänger geht, eine Anfrage vorausgeht. Als rechtmäßig würde dann sogar ein Trojanisches Pferd eingestuft, das eingeschleust von innen heraus eine Verbindung über tcp/80 zum Rechner des Angreifers aufbaut. Die Inhalte der Pakete bleiben bei der Prüfung außen vor.

Leider gerät immer wieder in Vergessenheit, dass heutige Firewall-Systeme nur auf Netzwerkebene absichern. Gegen mögliche Angriffe auf Anwendungsebene bieten sie keinen Schutz. Dies ist aber, wie gesagt, kein Problem von Soap, sondern aller Web-Anwendungen. So gefährdeten Web-Würmer wie Code Red oder Nimda nicht, wie fälschlicherweise oft angenommen, nur Mail-Systeme, sondern auch Web-Server.

Generalüberholung angesagt

Verteilte Applikationen auf Basis von Corba oder DCOM lassen sich hier ein bisschen besser als Web-Services durch die Firewall schützen, weil diesen zumindest ein eigener Port zugeordnet werden muss. Aber als das Gelbe vom Ei kann auch dies nicht bezeichnet werden. Die Intrusion-Detection-Systeme arbeiten ebenfalls auf Netzwerkebene und erkennen keine Manipulationen in den Anwendungspaketen. Angriffe auf Web-Anwendungen bleiben so leicht unerkannt. Die Diskussion um die mangelnde Sicherheit einer Zukunftstechnologie bietet also durchaus eine gute Gelegenheit, den Status quo in Sachen Anwendungssicherheit unter die Lupe zu nehmen.

Kritische Punkte sind die Authentizität und Integrität der Transaktionen sowie die Vertraulichkeit der Information. Mittels Verschlüsselung und Authentisierung lassen sich hier gute Sicherheitsstandards erreichen. Die in WS-Security für sichere Web-Services vorgeschlagenen Soap-Erweiterungen sehen unter anderem die Integration von Public Key Infrastructure (PKI), Kerberos und Secure Sockets Layer (SSL) vor und unterscheiden sich damit nicht wesentlich von dem, was allgemein für Web-Anwendungen als nötig angesehen wird. Vor allem, wenn diese mehr bieten sollen als die pure Bereitstellung von Informationen ohne Verbindung zu internen Systemen.

Derzeit hat bei diesen Web-Applikationen vor allem SSL Konjunktur. Doch dabei wird die Berechtigung einer Anfrage nicht geprüft. Eine PKI verfolgt dagegen einen umfassenderen Ansatz. Aber es dürfte sich mittlerweile die Erkenntnis durchgesetzt haben, dass aller vor wenigen Jahren herrschenden Euphorie zum Trotz die Erfolgsmeldungen realisierter Projekte ausbleiben. Das Infrastruktur-geprägte Vorgehen gilt als zu teuer, zu aufwändig und als nur schwer realisierbar. Hier bleibt abzuwarten, ob die Web-Services eine Trendumkehr anstoßen oder ob weiterhin die punktuellen Authentisierungs- und Verschlüsselungslösungen die Oberhand behalten. Microsoft hat zumindest vor kurzem ein Security-Paket mit dem Codenamen Trustbridge angekündigt, das im nächsten Jahr auf den Markt kommen und es Firmen ermöglichen soll, Benutzer-IDs über Unternehmens- und Anwendungsgrenzen hinaus zu authentifizieren.

Ein anderes Thema sind manipulierte CGI-Skripte. Mit diesen lassen sich Werte in der Datenbank ändern, beispielsweise Preisinformationen, wenn der Programmierer nicht schon im Vorfeld an dieses mögliche Leck gedacht hat und im CGI-Skript die Eingaben prüfen lässt, bevor sie als SQL-Statement weitergeleitet werden. Auch Ausführungsbefehle lassen sich in Eingabeformularen verstecken. Einige Datenbanken akzeptieren neben reinen SQL-Anfragen auf die Daten auch in SQL-Befehle eingebettete Skriptsprachen wie Visual Basic und können so die Voraussetzungen für einen Zugriff auf das darunterliegende Betriebssystem schaffen. "Man muss sich bei der Analyse von Sicherheitsschwächen davon lösen, dass ein Angreifer in ein Eingabefeld für Artikelnummern auch nur Nummern eingibt", warnt der Heilbronner Sicherheitsexperte Stefan Strobel. Intern weitergeleitete Parameter, etwa Mail-Adressen von Kunden für spätere Bestellbestätigungen, sind ebenfalls für einen Missbrauch geeignet. Nicht unbedenklich sind auch die Cookies, die erstens oft interessante Informationen enthalten und zweitens inhaltlich leicht veränderbar sind.

Soap schafft hier keine neuen Verhältnisse, sondern bietet nur eine weitere Möglichkeit, Schwachpunkte in der Programmierung auszunutzen. "Viele Angriffe auf Soap sind eigentlich HTTP-Angriffe in einem Soap-Envelope beziehungsweise Dinge wie SQL-Injection, die auch über Soap funktionieren", erläutert Strobel. Im Soap-Envelope sind die Nachrichteninhalte, ihr Ziel sowie Informationen über notwenige Elemente spezifiziert. Darüber hinaus sind Web-Services genauso anfällig gegen Denial-of-Service-Angriffe oder Buffer Overflows wie andere Web-Technologien auch.

Proxy-Firewalls nötig

Für Web-Anwendungen - unabhängig ob Soap oder herkömmliche Technologien - sind auf jeden Fall weitere Sicherheitsmaßnahmen erforderlich. Experten fordern so genannte Proxy-Firewalls, die in die Datenpakete hineinschauen. Doch allzu groß ist die Auswahl hier noch nicht. Ein Produkt ist beispielsweise "Appshield". Die BSH Bosch und Siemens Hausgeräte GmbH hat damit einen Brückenschlag zwischen dem SAP Web Application Server und dem Internet gemacht. Nun greifen die Fachhändler direkt über das B-2-B-Portal auf die ERP-Systeme des Unternehmens zu. Ebenfalls in die Kategorie Application-Firewall fällt "Interdo" von Kavado. Die Lösung kann Soap immerhin zu einem erheblichen Teil absichern, indem die Soap-Nachrichten quasi ausgepackt und mit den Software-spezifischen Security-Pipes durchgecheckt werden. "SQL-Injection innerhalb von Soap sowie klassische HTTP-Angriffe auf Soap lassen sich damit verhindern", weiß Strobel. "Eine semantische Filterung der Inhalte bestimmter Objekte oder Nachrichten, wie es beispielsweise Xtradyne bei Corba-Nachrichten macht, ist allerdings noch nicht möglich."

Diskutiert wird im Zusammenhang mit den Web-Services auch das Thema sicheres Betriebssystem. Zwar gibt es mittlerweile die Trusted Operating Systems, speziell abgesicherte Versionen von Betriebssystemen, etwa auf Basis von Solaris. Gegen Angriffe auf der Anwendungsebene können sie jedoch nicht schützen. Gelingt einem Angreifer der Durchbruch, etwa über manipulierte CGI-Skripts, dann sind die Folgen für das Betriebssystem begrenzt. Bei einem geringeren Sicherheitsbedarf kann es hier allerdings auch ausreichen, das Standard-Betriebssystem speziell zu härten. (sra)

*Stefanie Schneider ist freie Fachjournalistin für IT-Sicherheitsthemen in Mittbach.

Sicherheitsprobleme

- Firewalls beurteilen nur, ob es sich um rechtmäßigen HTTP-Verkehr handelt oder nicht

- Keine Überprüfung, ob dem Datenverkehr eine Anfrage vorausgegangen ist

- Firewalls und Intrusion-Detection-Systeme schützen nur die Netzwerkebene

- Webwürmer wie Code Red oder Nimda

- manipulierte CGI-Skripte

- Denial-of-Service-Attacken

- Buffer Overflows

- Betriebssystem

Abb.1: Schutzumfang von Firewalls

Die heute gängigen Firewalls schützen nur auf Netzwerkebene. Die obersten drei Ebenen des ISO/OSI-Schichtenmodells beziehungsweise die Application-Ebene des TCP/IP-Protokollstapels sind ungeschützt. Quelle: Schneider

Abb.2: Hindernisse für eine Verwendung von Web-Services

60 Prozent aller Anwender sehen in Sicherheitslücken das größte Hemmnis für den Einsatz von Web-Services. Quelle: Cap Gemini Ernst & Young, Juni 2002