Sicherheit von Web-Services

INHALTSVERZEICHNIS

Abkurzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung

2 Einzelne Sicherheitsaspekte
2.1 Sicherheitsaspekte der Umgebung
2.2 Sicherheitsaspekte der Anwendung
2.3 Sicherheitsaspekte des Transports
2.3.1 Ein Beispiel fu¨r verteilte Web-Services
2.3.2 Vertraulichkeit
2.3.3 Integrit¨at
2.3.4 Authentifizierung
2.3.5 Transportprotokolle
2.3.6 Denial of Service
2.4 Sicherheitsaspekte von UDDI

3 Herkommliche Losungen
3.1 Vertraulicher Transport durch Verschlu¨sselung
3.2 Wahrung der Integrit¨at durch digitale Signaturen
3.3 Authentifizierungssysteme

4 Sicherheitsstandards fu¨r Web-Services
4.1 Authentifizierung und Authorisierung mit SAML
4.2 Integrit¨atspru¨fung mit XML-Signature
4.3 Vertraulichkeit durch XML-Encryption
4.4 Alles vereint: WS-Security
4.5 Sicherheitsmechanismen fu¨r UDDI

5 Fazit

Erkl¨arung zur Seminararbeit

A Beispiel zu WS-Security

Literaturverzeichnis

Abku¨rzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

1 Gr¨oßte Hindernisse fu¨r die Implementierung von Web Services

2 U¨ blicher U¨ bertragungsweg im Internet

3 Ein Beispiel fu¨r verteilte Web-Services

4 Funktionsweise von digitalen Signaturen

5 Beispiel fu¨r eine SOAP-Nachricht mit SAML-Elementen

1 Einleitung

Die Technologie der Web-Services unterscheidet sich von der bisheriger Web Appli- kationen. Ein simples Client-/Server-Modell reicht zu ihrer Beschreibung nicht aus. Vielmehr sind Web-Services konzipiert, um plattform- und entfernungsunabh¨angig in großer Zahl automatisch miteinander zu kommunizieren. Durch Standardisierung der Schnittstellen und Verwendung von XML (Extensible Markup Language) als Datenaustauschformat soll die Integration zwischen verschiedenen Systemen verein- facht werden. Dem steht aber die Entstehung neuer Sicherheitsprobleme entgegen.

Aus einer Studie¹ der Evans Data Corporation unter 401 Managern in den USA

Abbildung in dieser Leseprobe nicht enthalten

geht hervor, dass das gr¨oßte Hindernis vor der Nutzung von Web-Services die un- gel¨osten Sicherheitsprobleme sind (siehe Abbildung 1). Welche Sicherheitsaspekte in diesem Zusammenhang kritisch sind und wie sie gel¨ost werden k¨onnen ist Inhalt dieser Arbeit. Dazu erfolgt eine kurze Beschreibung typischer Sicherheitsaspekte von Web-Services und die Vorstellung und Diskussion heutiger L¨osungen. Schließ- lich werden aktuelle Entwicklungen spezialisierter Sicherheitsstandards dargestellt und bewertet.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Evans Data Corporation

Abbildung 1: Gr¨oßte Hindernisse fu¨r die Implementierung von Web Services

2 Einzelne Sicherheitsaspekte

Bei der Absicherung von Web-Services kann man die kritischen Bereiche einteilen in das System, in das der Web-Service eingebettet ist (Umgebung), die eigentliche Implementierung des Web-Service (Anwendung) und die U¨ bertragung von Nachrich- ten zwischen Web-Services (Transport).² Weiterhin stellt auch das Katalogsystem UDDI (Universal Description, Discovery and Integration) ein spezielles Sicherheits- risiko von Web-Services dar.

2.1 Sicherheitsaspekte der Umgebung

Umgebung ist hier die Hard- und Softwareplattform, auf der ein Web-Service l¨auft. Die Hardware spielt beim Thema Sicherheit von Web-Services eine untergeord- nete Rolle, weil Web-Services keine spezielle Hardware ben¨otigen und somit exi- stierende L¨osungen weiterhin eingesetzt werden k¨onnen. Ausnahmen k¨onnen z.B. neu betriebene XML-Application-Firewalls auf Hardwarebasis sein. Diese Firewalls pru¨fen ankommende Nachrichten auf Konformit¨at mit der formalen Schnittstellen- beschreibung des adressierten Web-Service. Auf diese Weise k¨onnen Nachrichten mit illegalen Parametern entdeckt und aussortiert werden. Bei Verwendung von XML-

Application-Firewalls muss das Sicherheitskonzept erweitert und die Konfiguration dementsprechend angepasst werden.³

Auf der Softwareseite ist die Sicherheit dafu¨r umso schwieriger zu handhaben. Die Weiterentwicklung von Betriebssystemen und Webservern ist in aller Regel dem Einfluss des Web-Service Anbieters entzogen. Seine Absicherungsm¨oglichkeiten be- schr¨anken sich somit auf die st¨andige Aktualisierung der Software. Durch die Kom- plexit¨at von Betriebssystemen und Webservern ist ihre Fehleranf¨alligkeit enorm hoch, und dennoch sind in dieser Hinsicht keine umfassenden L¨osungsans¨atze er- kennbar.

2.2 Sicherheitsaspekte der Anwendung

Abbildung in dieser Leseprobe nicht enthalten

Durch (bewusst oder unbewusst) fehlerhafte Modellierung oder Implementierung ei- nes Web-Service k¨onnen beliebige Sicherheitslu¨cken entstehen. Potentielle Angreifer

mu¨ssen diese aber kennen, um einen Angriff auszufu¨hren. Insbesondere muss ein Angreifer die Schnittstelle des Web-Service kennen, um mit ihm kommunizieren zu k¨onnen. Gerade in der Ver¨offentlichung⁴ dieser Schnittstelleninformation liegt aber auch der gr¨oßte Nutzen von Web-Services, denn nur so k¨onnen sie automatisch in- teragieren.

Im Gegensatz zu herk¨ommlichen Web-Applikationen werden Web-Services ge- w¨ohnlich

u¨ber entfernte Prozeduraufrufe angesprochen. Ein Angreifer kann also

einzelne Prozeduren eines Web-Service aufrufen und dabei die Parameter beliebig w¨ahlen. Bei der Implementierung mu¨ssen also auch beabsichtigt unsinnige Parame- ter beru¨cksichtigt werden. Dies macht die Absicherung der Anwendung viel schwie- riger und auf die korrekte Modellierung und Implementierung von Web-Services

muss ein noch gr¨oßeres Augenmerk gelegt werden als bisher bei Web-Applikationen.⁵

Leider wird dies durch moderne Entwicklungsumgebungen nicht gew¨ahrleistet, im Gegenteil: Sie gef¨ahrden die Sicherheit, weil schon Laien komplexe Web-Services im- plementieren k¨onnen, ohne dabei auf oben genannte Probleme eingehen zu mu¨ssen.⁶ Typische Fehlerquellen k¨onnen so zu einfachen Angriffspunkten werden.

Es ist mathematisch unentscheidbar, ob ein Web-Service fehlerhaft ist. Man kann also von außen nicht erkennen, ob ein Web-Service das ausfu¨hrt, was man von ihm er- wartet. Dies und die anderen Probleme werden dazu fu¨hren, dass die Akzeptanz ein- zelner Web-Services vom Vertrauen gegenu¨ber dem Anbieter abh¨angen wird. Daher

w¨are es wichtig im Sinne der Sicherheit, wenn auch Sicherheitsinformationen u¨ber einen Web-Service in seiner Schnittstellenbeschreibung dargestellt werden k¨onnten.⁷

2.3 Sicherheitsaspekte des Transports

Web-Services verschicken untereinander Nachrichten. Auf dem Weg vom Sender zum Empf¨anger ist eine Nachricht am wenigsten geschu¨tzt. Auf dem u¨blichen U¨ bertra- gungsweg durch das Internet (siehe Abbildung 2) l¨auft die Nachricht durch eine unbestimmte Zahl von Drittsystemen, denen nicht vertraut werden kann.

Es ist daher n¨otig, die Nachricht vor unberechtigtem Zugriff auf diesen Dritt- systemen zu schu¨tzen. Angreifer sollen die Nachricht nicht lesen (Vertraulichkeit)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: U¨ blicher U¨ bertragungsweg im Internet

oder unbemerkt ver¨andern k¨onnen (Integrita¨t). Durch Authentifizierung wird ver- hindert, dass sich ein unberechtigter Angreifer als berechtigt ausgeben kann. Bis hierher gleichen die Anforderungen denen herk¨ommlicher Transaktionen im Internet. Web-Services interagieren jedoch verteilt und in großer Zahl in komplexen Prozes- sen. Auf dieselbe Nachricht mu¨ssen verschiedene Web-Services so zugreifen k¨onnen, dass jeder Web-Service nur die Daten sehen oder bearbeiten kann, die ihm zustehen. Nachrichten nach dem Standard SOAP (Simple Object Access Protocol) k¨onnen u¨ber beliebige Transportwege versendet werden. Deshalb muss auch das verwendete

Transportprotokoll Anforderungen an die Sicherheit erfu¨llen.

Ein Angreifer kann einen Web-Service mit Anfragen derart u¨berfordern, dass die- ser nicht mehr auf Anfragen von anderen Web-Services reagieren kann. Dieses Pro- blem der Dienstverweigerung (engl. Denial of Service) betrifft Web-Services ebenso wie jede andere Web-Applikation. In verteilten Prozessen wirkt sich dieser Angriff aber viel st¨arker aus, denn mit dem Ausfall nur eines nicht zu ersetzenden Gliedes ist der gesamte Prozess lahmgelegt.

2.3.1 Ein Beispiel fu¨r verteilte Web-Services

Ein Beispiel fu¨r verteilte Web-Services zeigt Abbildung 3. An der Abwicklung eines Gesch¨aftsprozesses sind typischerweise mehrere Web-Services auf (nicht notwendi- gerweise) unterschiedlichen Systemen beteiligt. Durch die UDDI-Registrierung wird es m¨oglich, einen Web-Service zu nutzen, ohne seine tats¨achliche Adresse zu kennen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Ein Beispiel fu¨r verteilte Web-Services

Hier k¨onnte man sich vorstellen, Web-Service A w¨are eine Kreditkartenlesesoftwa- re in einem Kassensystem, die die Kreditkartendaten an die Rechnungsabteilung des Unternehmens schickt (Web-Service B). Diese sucht sich per UDDI einen Web- Service des Kreditkartenunternehmens, der die Daten verifizieren kann (Web-Service C).⁸ Web-Service C meldet die Abfrage zum Zwecke der Speicherung von Kunden-

daten an Web-Service D weiter und berichtet Web-Service B u¨ber das Ergebnis der Verifikation. Web-Service B vollzieht nun die Transaktion und meldet den Erfolg an Web-Service A zuru¨ck oder lehnt die Kreditkarte ab.

An diesem Beispiel kann man erkennen, dass die gleiche Nachricht von unter- schiedlichen Web-Services verarbeitet wird. Bei der Modellierung mu¨ssen die un- terschiedlichen Rollen der beteiligten Web-Services beru¨cksichtigt werden, um den korrekten Umgang mit sicherheitskritischen Informationen zu gew¨ahrleisten. Die Si- cherheitsinfrastruktur muss die Implementierung der Modellierung allerdings auch technisch erm¨oglichen.

2.3.2 Vertraulichkeit

Eine SOAP-Nachricht enth¨alt h¨aufig Daten, die nur fu¨r bestimmte Parteien lesbar sein sollen. Im einfachsten Fall handelt es sich dabei um Sender und Empf¨anger. Dann reduziert sich das Problem auf die Absicherung des Informationskanals und kann mit herk¨ommlichen Mitteln gel¨ost werden.⁹

Eventuell werden jedoch Intermedi¨are in einen Prozess eingebunden, die nur Tei- le der Daten kennen sollen. Es muss daher ein Mechanismus zur Verfu¨gung stehen, mit dessen Hilfe einzelne Elemente der Nachricht verschlu¨sselt werden k¨onnen. Da- zu ist kein neues Kryptografieverfahren n¨otig, sondern die Anwendung bisheriger Verfahren in einem neuen Kontext. Die Elemente einer SOAP-Nachricht mu¨ssen mit beliebigen kryptografischen Verfahren verschlu¨sselt werden k¨onnen, damit auch Web-Services mit propriet¨aren Verfahren in der Lage sind, diese einzusetzen. Ebenso muss ein Intermedi¨ar weitere Elemente zu einer Nachricht hinzufu¨gen und sie selber verschlu¨sseln k¨onnen.

2.3.3 Integrit¨at

Die Integrit¨at einer Nachricht ist gew¨ahrleistet, wenn keine A¨ nderung an der Nach- richt vorgenommen werden kann, ohne dass der Empf¨anger dies bemerkt. Auch hier muss es m¨oglich sein, einzelne Elemente einer Nachricht zu schu¨tzen, weil Interme- di¨are vielleicht Teile der Nachricht ¨andern oder Elemente erg¨anzen k¨onnen sollen. Wie bei der Vertraulichkeit w¨are es auch hier wu¨nschenswert, beliebige Verfahren nutzen zu k¨onnen. Insofern stellen Integrit¨at und Vertraulichkeit ¨ahnliche Anforde- rungen an Web-Services.

2.3.4 Authentifizierung

Eventuell soll der Zugriff auf einen Web-Service so eingeschr¨ankt werden, dass nur Berechtigte mit ihm kommunizieren du¨rfen. Ein Web-Service muss also pru¨fen k¨onnen, ob eine SOAP-Nachricht von einem berechtigten Web-Service oder einer berechtigten Person abgesendet worden ist. Dazu muss der Absender einer SOAP- Nachricht in der Lage sein, ihre Identit¨at zu beweisen. Wenn Intermedi¨are einge- bunden werden, mu¨ssen auch Teile der Daten authentifiziert werden k¨onnen (z.B.

[...]

¹ o.V. (2002b)

² Vgl. o.V. (2002d)

³ Vgl. Champion (2002)

⁴ U¨ blicherweise per UDDI, siehe auch Abschnitt 2.4.

⁵ Vgl. Treese (2002)

⁶ Vgl. Ranft (2002)

⁷ Vgl. Fernandez (2002)

⁸ Die UDDI-Beschreibung von Web-Service C muss so gestaltet sein, dass Web-Service B ihn finden kann. Siehe auch Abschnitt 4.5 zu diesem Problem.

⁹ Z.B. mit SSL, vgl. Abschnitt 3.1