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 Studie1 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).2 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.3
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¨offentlichung4 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.5
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.6 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.7
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).8 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.9
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.
[...]
1 o.V. (2002b)
2 Vgl. o.V. (2002d)
3 Vgl. Champion (2002)
4 U¨ blicherweise per UDDI, siehe auch Abschnitt 2.4.
5 Vgl. Treese (2002)
6 Vgl. Ranft (2002)
7 Vgl. Fernandez (2002)
8 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.
9 Z.B. mit SSL, vgl. Abschnitt 3.1
- Arbeit zitieren
- Dominik Strecker (Autor:in), 2003, Sicherheit von Web-Services, München, GRIN Verlag, https://www.grin.com/document/108594
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.