Universit t Karlsruhe (TH)
Fakult¨at f¨ur Wirtschaftswissenschaften
Lehrstuhl f¨ur Informations-
betriebswirtschaftslehre (IW)
Seminararbeit
Sicherheit von Web-Services
von
Cand.Inform.Wirt Dominik Strecker
16.01.2003
INHALTSVERZEICHNIS
ii
Inhaltsverzeichnis
Abk¨
urzungsverzeichnis
iii
Abbildungsverzeichnis
iii
1 Einleitung
1
2 Einzelne Sicherheitsaspekte
2
2.1 Sicherheitsaspekte der Umgebung . . . . . . . . . . . . . . . . . . . .
2
2.2 Sicherheitsaspekte der Anwendung . . . . . . . . . . . . . . . . . . .
2
2.3 Sicherheitsaspekte des Transports . . . . . . . . . . . . . . . . . . . .
3
2.3.1
Ein Beispiel f¨ur verteilte Web-Services . . . . . . . . . . . . .
4
2.3.2
Vertraulichkeit . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.3
Integrit¨at . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.4
Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.5
Transportprotokolle . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.6
Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4 Sicherheitsaspekte von UDDI . . . . . . . . . . . . . . . . . . . . . .
8
3 Herk¨
ommliche L¨
osungen
8
3.1 Vertraulicher Transport durch Verschl¨usselung . . . . . . . . . . . . .
9
3.2 Wahrung der Integrit¨at durch digitale Signaturen . . . . . . . . . . .
9
3.3 Authentifizierungssysteme . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Sicherheitsstandards f¨
ur Web-Services
11
4.1 Authentifizierung und Authorisierung mit SAML . . . . . . . . . . . 12
4.2 Integrit¨atspr¨ufung mit XML-Signature . . . . . . . . . . . . . . . . . 13
4.3 Vertraulichkeit durch XML-Encryption . . . . . . . . . . . . . . . . . 13
4.4 Alles vereint: WS-Security . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5 Sicherheitsmechanismen f¨ur UDDI . . . . . . . . . . . . . . . . . . . . 14
5 Fazit
15
Erkl¨
arung zur Seminararbeit
iv
A Beispiel zu WS-Security
v
Literaturverzeichnis
vi
ABK ¨
URZUNGS- UND ABBILDUNGSVERZEICHNIS
iii
Abk¨
urzungsverzeichnis
HTTP
Hypertext Transfer Protocol
OASIS
The Organization for the Advancement
of Structured Information Standards
SAML
Security Assertion Markup Language
SOAP
Simple Object Access Protocol
SSL
Secure Socket Layer
TLS
Transport Layer Security
UDDI
Universal Description, Discovery and Integration
W3C
World Wide Web Consortium
WS-Security Web Services Security Language
XML
Extensible Markup Language
Abbildungsverzeichnis
1
Gr¨oßte Hindernisse f¨ur die Implementierung von Web Services . . . .
1
2
¨
Ublicher ¨
Ubertragungsweg im Internet . . . . . . . . . . . . . . . . .
4
3
Ein Beispiel f¨ur verteilte Web-Services . . . . . . . . . . . . . . . . .
5
4
Funktionsweise von digitalen Signaturen . . . . . . . . . . . . . . . . 10
5
Beispiel f¨ur eine SOAP-Nachricht mit SAML-Elementen . . . . . . . 12
1 EINLEITUNG
1
"
The real switch in thinking is that we
might be able to make these services
available to 'silicon-based life forms'."
James Gosling
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
1
der Evans Data Corporation unter 401 Managern in den USA
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.
Sicherheits- und Authentifikationsbelange
46,9 %
Bandbreiten- und Zugangsbelange
21,4 %
Interoperatibilit¨atsprobleme
13,2 %
Erreichen einer kritischen Masse von verf¨ugbaren Services
12,0 %
Sonstiges
5,0 %
Keine Antwort
1,5 %
Quelle: Evans Data Corporation
Abbildung 1: Gr¨oßte Hindernisse f¨ur die Implementierung von Web Services
1
o.V. (2002b)
2 EINZELNE SICHERHEITSASPEKTE
2
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 ¨
Ubertragung 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
pr¨ufen 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 daf¨ur 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
Durch (bewusst oder unbewusst) fehlerhafte Modellierung oder Implementierung ei-
nes Web-Service k¨onnen beliebige Sicherheitsl¨ucken entstehen. Potentielle Angreifer
2
Vgl. o.V. (2002d)
3
Vgl. Champion (2002)
2 EINZELNE SICHERHEITSASPEKTE
3
m¨ussen diese aber kennen, um einen Angriff auszuf¨uhren. Insbesondere muss ein
Angreifer die Schnittstelle des Web-Service kennen, um mit ihm kommunizieren zu
k¨onnen. Gerade in der Ver¨offentlichung
4
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 ¨uber entfernte Prozeduraufrufe angesprochen. Ein Angreifer kann also
einzelne Prozeduren eines Web-Service aufrufen und dabei die Parameter beliebig
w¨ahlen. Bei der Implementierung m¨ussen also auch beabsichtigt unsinnige Parame-
ter ber¨ucksichtigt 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 m¨ussen.
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 ausf¨uhrt, was man von ihm er-
wartet. Dies und die anderen Probleme werden dazu f¨uhren, dass die Akzeptanz ein-
zelner Web-Services vom Vertrauen gegen¨uber dem Anbieter abh¨angen wird. Daher
w¨are es wichtig im Sinne der Sicherheit, wenn auch Sicherheitsinformationen ¨uber
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 gesch¨utzt. Auf dem ¨ublichen ¨
Ubertra-
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 sch¨utzen. Angreifer sollen die Nachricht nicht lesen (Vertraulichkeit)
4
¨
Ublicherweise per UDDI, siehe auch Abschnitt 2.4.
5
Vgl. Treese (2002)
6
Vgl. Ranft (2002)
7
Vgl. Fernandez (2002)
2 EINZELNE SICHERHEITSASPEKTE
4
Sender
Datenfluss
E Router X
ppp
Router Y
c
Empf¨anger
Abbildung 2: ¨
Ublicher ¨
Ubertragungsweg im Internet
oder unbemerkt ver¨andern k¨onnen (Integrit¨at). 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 m¨ussen 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
¨uber beliebige Transportwege versendet werden. Deshalb muss auch das verwendete
Transportprotokoll Anforderungen an die Sicherheit erf¨ullen.
Ein Angreifer kann einen Web-Service mit Anfragen derart ¨uberfordern, 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 f¨
ur verteilte Web-Services
Ein Beispiel f¨ur 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.
2 EINZELNE SICHERHEITSASPEKTE
5
Umgebung A
Web-Service A
1
E
'
5
Umgebung B
Web-Service B
'
2
Umgebung C
Web-Service C
c
3
Web-Service D
4
T
UDDI-
Registrierung
Abbildung 3: Ein Beispiel f¨ur 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 ¨uber das Ergebnis der
Verifikation. Web-Service B vollzieht nun die Transaktion und meldet den Erfolg an
Web-Service A zur¨uck 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 m¨ussen die un-
terschiedlichen Rollen der beteiligten Web-Services ber¨ucksichtigt werden, um den
korrekten Umgang mit sicherheitskritischen Informationen zu gew¨ahrleisten. Die Si-
cherheitsinfrastruktur muss die Implementierung der Modellierung allerdings auch
technisch erm¨oglichen.
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.
2 EINZELNE SICHERHEITSASPEKTE
6
2.3.2
Vertraulichkeit
Eine SOAP-Nachricht enth¨alt h¨aufig Daten, die nur f¨ur 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 Verf¨ugung stehen,
mit dessen Hilfe einzelne Elemente der Nachricht verschl¨usselt 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 m¨ussen
mit beliebigen kryptografischen Verfahren verschl¨usselt 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 hinzuf¨ugen und sie selber
verschl¨usseln k¨onnen.
2.3.3
Integrit¨
at
Die Integrit¨at einer Nachricht ist gew¨ahrleistet, wenn keine ¨
Anderung 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 sch¨utzen, 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 w¨unschenswert, 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 d¨urfen. Ein Web-Service muss also pr¨ufen
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, m¨ussen auch Teile der Daten authentifiziert werden k¨onnen (z.B.
9
Z.B. mit SSL, vgl. Abschnitt 3.1
2 EINZELNE SICHERHEITSASPEKTE
7
Best¨atigung der Korrektheit von Kreditkartendaten).
Wer seine Identit¨at beweisen will, muss einen Berechtigungsnachweis (engl. cre-
dential) erbringen um als berechtigt anerkannt zu werden. Die einfachste Form des
Berechtigungsnachweises ist ein Passwort. Gelangt jedoch jemand in Besitz des Be-
rechtigungsnachweis, so kann er sich erfolgreich als der Berechtigte ausgeben. Die
F¨alschungssicherheit des Berechtigungsnachweises ist also ein wichtiges Kriterium
f¨ur sichere Authentifizierung.
10
2.3.5
Transportprotokolle
Die Spezifikation der Web-Services schreibt kein spezielles Transportprotokoll vor,
aber bisher beschr¨ankt sich die Praxis auf das g¨angige Transportprotokoll HTTP
(Hypertext Transfer Protocol), das vor allem im Internet Verwendung findet. Dies
l¨asst sich vor allem durch die weite Verbreitung und mangelnde Alternativen er-
kl¨aren. HTTP hat aber Eigenschaften, die f¨ur die ¨
Ubertragung von SOAP-Nachrich-
ten wenig geeignet sind. So k¨onnen Nachrichten aufgrund der Struktur von HTTP
doppelt gesendet werden (sog. Replays), was dazu f¨uhren kann, das Transaktionen
f¨alschlicherweise zweimal ausgef¨uhrt werden.
Gef¨ahrlich ist in diesem Zusammenhang aber vor allem, dass HTTP f¨ur den
Transport von Internetseiten entworfen wurde und deshalb f¨ur gew¨ohnlich nicht von
einer Firewall geblockt wird. Wird eine SOAP-Nachricht ¨uber HTTP ¨ubertragen, hat
eine normale Firewall nicht die M¨oglichkeit, festzustellen, ob es sich um SOAP oder
eine Internetseite handelt. Auf diese Weise k¨onnen gef¨ahrliche SOAP-Nachrichten
direkt in das interne Netz eindringen.
11
2.3.6
Denial of Service
Durch die Bombardierung mit Anfragen kann ein Angreifer einen Web-Service prak-
tisch außer Kraft setzen. Dadurch wird auch jeder Web-Service blockiert, der auf den
lahmgelegten zugreifen muss. Dieses Problem ist schon theoretisch nicht zu l¨osen,
weil es gerade die Aufgabe von Web-Services ist, Anfragen zu bearbeiten. Auch wenn
nur Anfragen bestimmter Web-Services zugelassen werden, kann das Problem nicht
gel¨ost werden, denn der empfangende Web-Service (oder eine ¨ubergeordnete Instanz)
10
Vgl. Kirtland (2001)
11
Vgl. Treese (2002)
2 EINZELNE SICHERHEITSASPEKTE
8
muss die Herkunft einer jeden Nachricht pr¨ufen und kann auch mit dieser Aufgabe
¨uberfordert werden. Man kann Denial of Service-Attacken nicht verhindern, aber
man kann durch redundante Systeme (hier mehrere funktionsgleiche Web-Services)
die Anf¨alligkeit verringern.
12
2.4
Sicherheitsaspekte von UDDI
UDDI legt eine sog. Registrierung an, in der Informationen ¨uber Web-Services
ver¨offentlicht werden. Dadurch kann ein Web-Service gefunden und seine Schnitt-
stelle erkannt werden.
13
Ein Angreifer kann UDDI benutzen, um an interne Infor-
mationen zu gelangen oder sensible Daten abzufangen. Er kann die Registrierung
durchsuchen, um Schnittstellen zu Web-Services zu finden und f¨ur seine Zwecke zu
nutzen. Kritischer ist es aber, wenn er falsche Informationen ¨uber einen eigenen Web-
Service ver¨offentlicht, so dass dieser Nachrichten bekommt, die eigentlich f¨ur einen
anderen Web-Service bestimmt sind. Es muss also Authentifizierung in beide Rich-
tungen angeboten werden: Sowohl Sender als auch Empf¨anger einer UDDI-Anfrage
m¨ussen gezwungen werden k¨onnen, ihre Identit¨at zu beweisen.
3
Herk¨
ommliche L¨
osungen
SOAP selber bietet bewusst keinerlei Sicherheitsl¨osungen, weil es lediglich ein Rah-
menwerk definiert.
14
Diese Vernachl¨assigung hat sich als Fehler herausgestellt, denn
die mangelnde Sicherheit verhindert eine breite Akzeptanz f¨ur Web-Services. Auf der
anderen Seite verhindert die mangelnde Verbreitung von Web-Services wiederum ei-
ne z¨ugige L¨osung der Sicherheitsprobleme. Aus diesem Teufelskreis k¨onnen nur Indu-
striestandards heraushelfen. Solche auf die speziellen Bed¨urfnisse von Web-Services
zugeschnittene Sicherheitsstandards werden aktuell von großen Softwareherstellern
entwickelt (siehe Abschnitt 4). Der sp¨ate Einstieg in die Sicherheitsfragen kann sich
als schwerer Fehler erweisen, wenn die wahren Probleme nicht bedacht wurden und
unpraktikable Sicherheitsstandards entstanden sind.
15
12
Vgl. Clark (2002)
13
Vgl. Bellwood et al. (2002)
14
Vgl. Jeckle and Zengler (2002)
15
Vgl. Treese (2002)
3 HERK ¨
OMMLICHE L ¨
OSUNGEN
9
Momentan muss zur Absicherung noch auf herk¨ommliche L¨osungen zur¨uckge-
griffen werden. Dabei bieten sich sehr viele M¨oglichkeiten an, hier werden jedoch
nur einige wichtige Repr¨asentanten aufgef¨uhrt.
3.1
Vertraulicher Transport durch Verschl¨
usselung
Es gibt verschiedene Verfahren zur Verschl¨usselung des gesamten Informationska-
nals zwischen zwei Punkten. Das Prinzip dabei ist, zu Beginn der Kommunikation
einen geheimen Kommunikationsschl¨ussel f¨ur die anschließende Verbindung auszu-
handeln. Dabei muss nat¨urlich die Identit¨at der Teilnehmer gesichert sein, denn
sonst kann sich ein Angreifer in die Rolle eines Teilnehmers einschleichen und die
Verschl¨usselung aushebeln.
16
Mit SSL (Secure Socket Layer), bzw. dem Nachfolger TLS (Transport Layer Se-
curity) wird die Nachricht beim Sender verschl¨usselt und beim Empf¨anger wieder
entschl¨usselt. Auf dem Weg vom Sender zum Empf¨anger ist die Nachricht also gegen
unberechtigten Zugriff gesch¨utzt. Wird aber ein Intermedi¨ar eingebunden, m¨ussen
zwei verschl¨usselte Kan¨ale aufgebaut werden: Einer vom Sender zum Intermedi¨ar
und einer vom Intermedi¨ar zum Empf¨anger. Dadurch sieht der Intermedi¨ar aber im-
mer die gesamte Nachricht im Klartext. Dies ist f¨ur den verteilten Einsatz von Web-
Services absolut ungeeignet. Sollen Web-Services nur als Client-/Server-Applikation
mit standardisierter Schnittstelle fungieren, so reicht SSL dennoch aus.
17
F¨ur den Einsatz von Verschl¨usselung in SOAP-Nachrichten muss ein Verfahren
zur Verf¨ugung stehen, dass die Verschl¨usselung einzelner Teile der Nachricht f¨ur
einzelne Web-Services in einem komplexen Prozess erm¨oglicht. Mit Ende-zu-Ende-
Verschl¨usselung l¨asst sich das Problem nicht l¨osen.
3.2
Wahrung der Integrit¨
at durch digitale Signaturen
Mit Hilfe digitaler Signaturen kann verhindert werden, dass ein Angreifer eine Nach-
richt manipulieren kann. Gleichzeitig dient die digitale Signatur auch zur Pr¨ufung
der Authentizit¨at und Verbindlichkeit
18
. Abbildung 4 zeigt die Funktionsweise di-
16
sog. Man-In-The-Middle-Angriff
17
Vgl. Evans and Dowling (2002)
18
Verbindlichkeit bedeutet, dass der Absender nicht abstreiten kann, die Nachricht verfasst zu
haben.
3 HERK ¨
OMMLICHE L ¨
OSUNGEN
10
gitaler Signaturen. Aus der Nachricht wird ein sog. Hashwert berechnet. Dieser
ist praktisch f¨ur jede Nachricht eindeutig. Der Hashwert wird mit dem privaten
Schl¨ussel des Absenders verschl¨usselt. Wenn der Hashwert der Nachricht beim Em-
pf¨anger nicht mit dem des Senders ¨ubereinstimmt, so weiß der Empf¨anger, dass die
Nachricht ver¨andert wurde. Wenn der Hashwert nicht mit dem privaten Schl¨ussel
des Absenders verschl¨usselt wurde, weiß der Empf¨anger, dass die Nachricht nicht
vom Absender stammt.
Nachricht
c
Hashfunktion
Hashwert
c
geheimer Schl¨ussel
digitale Signatur
E
Datenfluss
E
Datenfluss
Sender
Nachricht
c
Hashfunktion
Vergleich
T
¨offentlicher Schl¨
ussel
digitale Signatur
Empf¨anger
Abbildung 4: Funktionsweise von digitalen Signaturen
Auch hier kann man mit herk¨ommlichen Methoden nur die gesamte Nachricht
signieren. Verteilte Web-Services arbeiten aber eventuell gemeinsam an einer Nach-
richt, so dass sich diese st¨andig ¨andert. Es wird also ein Verfahren ben¨otigt, dass die
Signierung einzelner Teile erm¨oglicht, damit gewollte ¨
Anderungen von ungewollten
unterschieden werden k¨onnen.
3.3
Authentifizierungssysteme
Die einfachste Art der Authentifizierung ist ein gemeinsames Geheimnis zwischen
den Kommunikationspartnern. Wenn einer der Partner seine Identit¨at beweisen will,
teilt er dem anderen einfach das Geheimnis mit. Das Geheimnis ist sein Berechti-
gungsnachweis. In dieser einfachen Welt ist leider auch der Angriff einfach: Derje-
nige, der das Geheimnis stiehlt, kann sich von nun an erfolgreich f¨ur den anderen
4 SICHERHEITSSTANDARDS F ¨
UR WEB-SERVICES
11
ausgeben. Diese Art der Authentifizierung ist zwar einfach zu implementieren, aber
auch unsicher. Ein Angreifer muss nur in Besitz des Geheimnisses gelangen, um
sich anschließend erfolgreich als Berechtigter auszugeben. Meist ist das Geheimnis
ein Passwort. Da Passw¨orter von Menschen im Ged¨achtnis behalten werden, sind
sie meist kurz und einfach. Schon durch ausprobieren
19
k¨onnen einfache Passw¨orter
schnell gefunden werden. Es gibt viele Authentifikationssysteme mit h¨oherer Si-
cherheit. Es widerspricht aber der Idee hinter Web-Services, wenn ein propriet¨ares
Authentifizierungssystem implementiert wird, weil dadurch nicht mehr mit standar-
disierten Web-Services kommuniziert werden kann. Dennoch ist es im Moment die
einzige M¨oglichkeit, einen Web-Service mit Authentifizierungsfunktionalit¨at auszu-
statten. Streng genommen kann man ihn damit aber nicht mehr als Web-Service
bezeichnen. Hier wird die Notwendigkeit eines Standards besonders deutlich.
4
Sicherheitsstandards f¨
ur Web-Services
Die fehlende Sicherheit von Web-Services hat zu einer wahren Flut von Standar-
disierungsvorhaben diverser Gruppen gef¨uhrt.
20
Viele dieser Standards sind kom-
plement¨ar, in einigen Bereichen haben sich aber auch konkurrierende Standards
gebildet. Z.B definieren SAML (Security Assertion Markup Language, siehe Ab-
schnitt 4.1) und WS-Security (Web Services Security Language, siehe Abschnitt 4.4)
jeweils unterschiedliche M¨oglichkeiten zur Repr¨asentation von Authentifizierungsin-
formationen in einer SOAP-Nachricht.
Die aussichtsreichsten Standards werden von den großen Gremien W3C (World
Wide Web Consortium) und OASIS (The Organization for the Advancement of
Structured Information Standards) entwickelt. Das W3C ist das wichtigste Stan-
dardisierungsgremium im Internet. ¨
Uber 350 der gr¨oßten IT-Unternehmen der Welt
sind dort Mitglied. OASIS ist ein Zusammenschluss sowohl großer IT-Unternehmen,
wie z.B. IBM und Microsoft, als auch Open-Source-Entwicklern aus aller Welt.
19
Z.B. durch sog. W¨orterbuchattacken
20
Vgl. Fontana (2002)
4 SICHERHEITSSTANDARDS F ¨
UR WEB-SERVICES
12
4.1
Authentifizierung und Authorisierung mit SAML
SAML ist eine Erweiterung f¨ur SOAP, die sich mit Authentifizierung und Authori-
sierung besch¨aftigt. Sie wird von OASIS entwickelt und ist in der Version 1.0 bereits
verabschiedet worden.
SAML definiert vor allem ein Element assertion, mit dem Identit¨at, Rolle
oder Eigenschaften einer Person zugesichert werden. Die Erteilung einer Zusicherung
erfolgt gegen Anfrage bei sog.
"
SAML authorities". Diese vertrauensw¨urdigen Stellen
k¨onnen beliebige (auch externe) Informationsquellen nutzen, um eine Anfrage zu
beantworten.
21
Nachteil von SAML ist, dass neben den SAML-Informationen keine weiteren
Daten in einer SOAP-Nachricht transportiert werden k¨onnen. Ein Beispiel f¨ur eine
SAML-Nachricht zeigt Abbildung 5. Die Nachricht ist eine Antwort auf eine Au-
thentifizierungsanfrage bei einer SAML-Autorit¨at. Sie erteilt eine assertion.
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
...
[10]
[11]
[12]
[13]
[14]
Quelle: Bindings and Profiles for the OASIS Security Assertion Markup Language
Abbildung 5: Beispiel f¨ur eine SOAP-Nachricht mit SAML-Elementen
21
Vgl. o.V. (2002a)
4 SICHERHEITSSTANDARDS F ¨
UR WEB-SERVICES
13
4.2
Integrit¨
atspr¨
ufung mit XML-Signature
Die Definition von digitalen Signaturen in Verbindung mit XML-Nachrichten folgt
dem XML-Signature Standard. XML-Signature ist eine Empfehlung des W3C. Wie
der Name schon sagt ist XML-Signature kein spezieller Web-Services-Standard, son-
dern f¨ur alle Daten in XML-Format geeignet. Da SOAP-Nachrichten XML-konform
sind, erf¨ullt XML-Signature die in Abschnitt 2.3.3 gestellten Anforderungen f¨ur den
Einsatz in SOAP-Nachrichten.
Mithilfe von XML-Signature kann elementweise sowohl die Integrit¨at als auch
Authentizit¨at der Daten gew¨ahrleistet werden. Dazu wird ein obligatorisches Ele-
ment signature eingef¨uhrt.
22
Es enth¨alt weitere Elemente, die wiederum Informa-
tionen zu den verwendeten Algorithmen, den ben¨otigten Schl¨usseln und die Signatur
an sich enthalten. Dabei ist wichtig, dass eine XML-Datei auch bei unterschiedlicher
Kodierung den gleichen Hash-Wert liefert. Zu diesem Zweck wird eine Kanonisierung
der XML-Datei durchgef¨uhrt, die eine einheitliche Repr¨asentation der XML-Daten
erreicht.
4.3
Vertraulichkeit durch XML-Encryption
XML-Encryption ist seit kurzem eine Empfehlung des W3C.
23
F¨ur XML-Encryption
gilt das im vorigen Abschnitt ¨uber XML-Signature und SOAP erw¨ahnte analog.
XML-Encryption legt fest, wie XML Nachrichten verschl¨usselt werden k¨onnen.
Dazu kann jedes einzelne XML-Element durch ein Element encrypteddata er-
setzt werden, dass die verschl¨usselten Daten und Informationen ¨uber verwendete
Mechanismen enth¨alt.
4.4
Alles vereint: WS-Security
Die Web Services Security Language (WS-Security, auch WSS oder Web Services
Security) wird ebenfalls von OASIS entwickelt. Es liegt noch keine verabschiede-
te Version vor. WS-Security orientiert sich eng an einer Roadmap
24
von IBM und
Microsoft. Sie definiert, wie Sicherheitsinformationen in eine SOAP-Nachricht ein-
gef¨ugt werden k¨onnen, ¨uberl¨asst aber die Verwendung konkreter Sicherheitsmecha-
22
Vgl. Bartel et al. (2001)
23
Vgl. Imamura et al. (2002)
24
Siehe o.V. (2002c)
4 SICHERHEITSSTANDARDS F ¨
UR WEB-SERVICES
14
nismen dem Entwickler. So k¨onnen alle oben genannten Standards in WS-Security
eingebunden werden. Durch eine solche Kombination kann eine umfassende Sicher-
heitsarchitektur implementiert werden.
WS-Security erweitert den SOAP-Header zur Unterst¨utzung umfangreicher Si-
cherheitsinfrastruktur. Außerdem stehen Hilfsmittel wie z.B. Zeitstempel zur Verf¨u-
gung, um Replays (siehe Abschnitt 2.3.5) zu verhindern. Mit WS-Security wird
das Element security eingef¨uhrt. Es kann beliebige XML-Elemente beinhalten,
WS-Security gibt aber auch Elemente vor. F¨ur die Authentifizierung werden von
WS-Security zwei Elemente bereitgestellt: usernametoken f¨ur einfache passwort-
basierte Authentifizierung und binarysecuritytoken f¨ur Kerberos-Tickets und
¨ahnliche Zertifikate. Auch SAML-Assertions k¨onnen mit WS-Security verwendet
werden.
25
Zur Signierung einer Nachricht wird das signature-Element aus dem
XML-Signature Standard (siehe Abschnitt 4.2) verwendet, zur Verschl¨usselung das
encrypteddata-Element von XML-Encryption (siehe Abschnitt 4.3). Anhang A
zeigt ein Beispiel zu WS-Security. Die SOAP-Nachricht enth¨alt Authentifizierungs-
informationen, ist signiert und verschl¨usselt. Zur Signierung und Verschl¨usselung
werden XML-Signature und XML-Encryption benutzt, die Authentifizierung l¨auft
¨uber WS-Security selbst.
4.5
Sicherheitsmechanismen f¨
ur UDDI
UDDI Version 3 definiert unter anderem das authinfo Element.
26
Damit kann
sicher gestellt werden, dass nur berechtigte Personen und Web-Services auf die In-
formationen in der Registrierung zugreifen k¨onnen. Die meisten Web-Services sollen
jedoch von jedermann genutzt werden k¨onnen. Durch Ver¨offentlichungen kann ein
Angreifer auf einfache Weise die Informationen erlangen, die er f¨ur die Vorberei-
tung eines Angriffs ben¨otigt. Diese Attacke kann nicht verhindert werden, bei der
Entwicklung von Web-Services muss deshalb besonders stark auf potentielle Sicher-
heitsl¨ucken eingegangen werden.
Es existiert in UDDI kein Standard f¨ur die einheitliche Beschreibung der Funk-
tionalit¨at eines Web-Service. Bei der Suche nach einem Web-Service mit ben¨otig-
ter Funktionalit¨at sollte man sich nicht auf die Beschreibung beschr¨anken, denn
25
Vgl. o.V. (2002e)
26
Vgl. Bellwood et al. (2002)
5 FAZIT
15
ein Angreifer kann f¨ur einen sch¨adlichen Web-Service eine gef¨alschte Beschreibung
hinterlegen und so einen anderen Web-Service vorgaukeln. Dieser Angriff trifft die
gr¨oßte Schwachstelle von UDDI und kann nur gel¨ost werden, indem bei der Suche
zus¨atzlich zur Beschreibung auch auf den Anbieter des Web-Service und den Autor
der UDDI-Informationen geachtet wird. Durch authinfo kann zwar die Authen-
tifizierung des Autors gew¨ahrleistet werden, die ¨
Uberpr¨ufung der Zertifikate oder
¨ahnlicher Berechtigungsnachweise bleibt aber dem Benutzer ¨uberlassen und damit
ein Sicherheitsrisiko.
5
Fazit
Der Erfolg von Web-Services wird davon abh¨angen, ob und wie sich die Technolo-
gie in der Praxis durchsetzt. Auf diesem Weg ist Sicherheit aus heutiger Sicht die
gr¨oßte H¨urde. Die heute existierenden L¨osungen helfen nicht wirklich weiter und
das Erreichen der kritischen Masse wird wohl erst nach Einf¨uhrung starker Sicher-
heitsstandards m¨oglich sein. Ob die Bem¨uhungen Fr¨uchte tragen werden muss sich
zeigen, die Aussichten sind aber gut.
27
27
Vgl. Wagner (2002)
A BEISPIEL ZU WS-SECURITY
v
A
Beispiel zu WS-Security
Zoe
FKJh...
2001-10-13T09:00:00Z
LyLsF0Pi4wPU...
DJbchm5gK...
KSFJ#%^%$^(...
Quelle: Web Services Security Core Specification
LITERATUR
vi
Literatur
Bartel et al. 2001
Bartel, Mark ; Boyer, John ; Fox, Barb ; LaMacchia,
Brian ; Simon, Ed: XML-Signature Syntax and Processing.
(2001). URL
http://www.w3.org/TR/xmldsig-core/. Access: 16.01.2003
Bellwood et al. 2002
Bellwood, Tom ; Cl´
ement, Luc ; Ehnebuske, Da-
vid ; Hately, Andrew ; Hondo, Maryann ; Husband, Yin L. ; Janus-
zewski, Karsten ; Lee, Sam ; McKee, Barbara ; Munter, Joel ; Riegen,
Claus von:
UDDI Version 3.0 Published Specification.
(2002).
URL
http://www.uddi.com/pubs/UDDI-V3.00-Published-20020719.pdf. Access:
16.01.2003
Champion 2002
Champion, Kerry: XML Web Services brauchen eine Firewall.
(2002). URL http://techupdate.zdnet.de/story/0,,s2121626,00.html.
Access: 16.01.2003
Clark 2002
Clark, David: Next-Generation Web Services. In: IEEE Internet
Computing March/April (2002), 1214
Evans and Dowling 2002
Evans, Sarah ; Dowling, Olwyn:
Is SSL
enough security for first-generation Web services?
(2002).
URL
http://www.webservices.org/index.php/article/articleview/529/. Ac-
cess: 16.01.2003
Fernandez
2002
Fernandez,
Eduardo
B.:
Web
Services
Se-
curity:
Current
status
and
the
future.
(2002).
URL
http://www.webservicesarchitect.com/content/articles/fernandez01.asp.
Access: 16.01.2003
Fontana 2002
Fontana, John: Securing Web Services. In: Network World 19
(2002) 38, 6465. ISSN 08877661
Imamura et al. 2002
Imamura, Takeshi ; Dillaway, Blair ; Simon,
Ed:
XML-Encryption Syntax and Processing.
(2002).
URL
http://www.w3.org/TR/xmlenc-core/. Access: 16.01.2003
LITERATUR
vii
Jeckle
and
Zengler
2002
Jeckle,
Mario
;
Zengler,
Barba-
ra:
SOAP - aber sicher.
In: OBJEKTSpektrum
1 (2002).
URL
http://www.jeckle.de/secureSOAP.html. Access: 16.01.2003
Kirtland
2001
Kirtland,
Mary:
Authentica-
tion
and
Authorization.
(2001).
URL
http://msdn.microsoft.com/library/en-us/dnservice/html/service02282001.asp.
Access: 16.01.2003
o.V.
2002a
o.V.:
Assertions and Protocol for the OASIS Se-
curity Assertion Markup Language (SAML).
(2002).
URL
http://www.oasis-open.org/committees/security/docs/cs-sstc-core-01.pdf.
Access: 16.01.2003
o.V. 2002b
o.V.:
Biggest Obstacle to Implementing Web Services.
In:
Enterprise Development Management Issues 2002
1 (2002).
URL
http://evansdata.com/enterpriseTOC 02-1 xmp1.htm. Access: 16.01.2003
o.V.
2002c
o.V.:
Security
in
a
Web
Services
World:
A
Proposed
Architecture
and
Roadmap.
(2002).
URL
http://www-106.ibm.com/developerworks/webservices/library/ws-secmap/.
Access: 16.01.2003
o.V.
2002d
o.V.:
Sichere
Web-Services
erfordern
exter-
ne
Tools.
In:
Computer
Zeitung
44
(2002).
URL
http://www.cirosec.de/pdf/berichterstattung/cz 28102002 1.pdf.
Access: 16.01.2003
o.V. 2002e
o.V.: Web Services Security SAML Token Binding. (2002). URL
http://www.oasis-open.org/committees/wss/documents/WSS-SAML-05.pdf.
Access: 16.01.2003
Ranft 2002
Ranft, Sabine: Web-Services sind nicht sicher genug. (2002). URL
http://www.computerwoche.de/index.cfm?pageid=259&artid=40159&type=detail.
Access: 16.01.2003
Treese 2002
Treese, Win: XML, web services, and XML. In: netWorker 6
(2002) 3, 912. ISSN 1091-3556
LITERATUR
viii
Wagner
2002
Wagner,
Raymond:
WS-Security
takes
good
step
toward
being
Web
service
standard.
(2002).
URL
http://www3.gartner.com/resources/107900/107940/107940.pdf.
Ac-
cess: 16.01.2003
0 Kommentare