Das bereits im oberen Abschnitt beschriebene SOAP bietet in Kombination mit Web Services natürlich enormes Potential für Unternehmen, jedoch wurde bei der Spezifikation keine Rücksicht auf Sicherheitsaspekte genommen. Führende Sicherheitsanalytiker wie z.B. Bruce Schneier sind darüber sehr besorgt und sehen eine neue Front im Sicherheitssektor.
 Abbildung 2: SOAP und Standard-Firewalls |
Was macht SOAP nun so gefährlich für
bestehende Sicherheitsarchitekturen? Das wichtigste Pro-Argument ist
auch die größte Sorge der Sicherheitsexperten, denn wie
schon Tim Bray, einer der Editoren der XML-Spezifikation so treffend
formuliert hat: „SOAP goes through firewalls like a knife through
butter“. Dieses von Microsoft explizit hervorgehobene Feature
macht bestehende Sicherheitskonzepte in Bezug auf SOAP obsolet, da
SOAP über den Standart http TCP-Port 80 oder über SMTP (TCP-Port
25) übermittelt wird und so jeglicher Kontrolle seitens der Firewalls
entrinnt (siehe Abb. 2). Damit kommt die Nachricht ungefiltert beim
Dienst an und hier offenbart sich das nächste Problem von SOAP.
Schließlich schickt man mittels SOAP Aufrufe und Daten an ein
mächtiges Applikationsinterface, welches noch dazu heterogen
und komplex ist. Es handelt sich ja um einen sich schnell weiterentwickelnden
und expandierenden Standard, welcher oft als P2P System nicht zentral
administriert ist und eine dynamische Verkettung erlaubt. Auch die Filterung von SOAP Messages sieht auf den ersten Blick eher schwierig aus. Erstens muss einmal erkannt werden, dass es sich bei dem http-Request um ein SOAP Envelope handelt. Sobald dies erledigt ist, können die XML Daten geparst werden, jedoch ergeben sich dabei neue Probleme beim internen Aufbau von SOAP. SOAP hat kein einheitliches Adressmodel oder eine verpflichtende interne Struktur wie http. Ab und zu gibt es einen Header, es kann aber auch keinen geben, ab und zu ist der Body RPC-encoded, ab und zu wieder nicht, ab und zu gibt es einen Methodenamen usw., dies wurde auch schon frühzeitig von Roy Fielding [Fielding 2000], einem der Erfinder von http erkannt. |
SOAP Sicherheitsanforderungen
Bevor man nun an die Ausarbeitung einer Lösung geht muss man sich
fragen welche Sicherheitsanforderungen nun an SOAP gestellt werden müssen.
In Prinzip gelten für Web Services die gleichen elementaren Sicherheitsanforderungen
wie für Standard Web Anwendungen. Dabei kann auch auf bewährte
Konzepte zurückgegriffen werden.
Folgende Sicherheitsgrundkonzepte müssen Web Services auf jeden Fall
genügen:
• Verbindlichkeit
Dadurch wird die Identität des Senders und des Empfängers überprüft,
wobei Authentifizierungsdaten entweder in den Headers oder im Body der
SOAP Nachricht eingebettet sein können. Standard Web Technologien
wie Passwörter(Basic Authentication), X.509 Zertifikate, Kerberos,
LDAP oder Active Directory können genutzt werden um Anfragen zu authentifizieren,
wobei sowohl Sender als auch Empfänger bei sensiblen Daten authentifiziert
werden sollten. Aufbauend darauf können dann feinkörnige Rechte
vergeben werden, welcher User welche Web Services wie ansprechen darf
und welche Daten wie von dem Benutzer oder einem anderen Programm auf
welche Weise verändert werden dürfen.
• Vertraulichkeit
Die Standard SSL-Verschlüsselung über HTTPS zwischen zwei Partnern
ist zwar möglich, jedoch für Web Services sehr oft nur suboptimal,
da oft nicht nur ein, sondern mehrere Partner an einer Kommunikation beteiligt
sind und der Service Provider nicht das letztendliche Ziel darstellt,
sondern selbst die Anfrage an mehrere Web Services weiterleitet. Hier
bietet der XML Encrypton Standard Abhilfe, welcher es erlaubt nur die
sensitiven Teile einer SOAP Nachricht zu verschlüsseln und damit
Header und andere für das Processing relevante Daten unverschlüsselt
zu übertragen. Somit ist es auch möglich im oben erwähnten
Szenario den verschlüsselten Inhalt solange weiterzuleiten bis er
am letztendlichen Ziel angelangt ist und damit echte Ende zu Ende Verschlüsselung
zu erlauben.
• Verfügbarkeit
Ein Service bietet nur solange einen Nutzen, solange er zuverlässig
erreichbar ist. Hierbei kommen typische Webtechnologien wie Load Balancing
und Proxies zum Einsatz eine Technik gegen SOAP-DoS Attacken wird später
bei der vorgeschlagenen Applikation Level Firewall erläutert.
• Integrität
Digitale Signaturen können benutzt werde, um herauszufinden, ob eine
Nachricht auf Ihrem Weg verändert wurde. Dabei kann z.B. Asymmetrische
Verschlüsselung zum Einsatz kommen, d.h. dass ein Client eine Nachricht
mit seinem privaten Schlüssel verschlüsselt und der Anbieter
des Services die Integrität der Nachricht mittels des öffentlichen
Schlüssels des Clients überprüfen kann. Dabei kommt aus
den unter Vertraulichkeit bekannten Problem der multiplen Ziele der XML
Signatur Standard ins Spiel, mit welchem wieder nur spezifische teile
der SOAP Nachricht signiert werden und so echte Ende zu Ende Integrität
versichert.
Zusätzlich zu den oben genannten Eigenschaften muss bei der Implementierung
von Sicherheitslösungen von Web Services speziell auf die Interoperabilität
von Sicherheitsmaßnahmen, auf die Skalierbarkeit, ein zentralisiertes
Management für mehrere kooperierende WS und speziell natürlich
auf die unterschiedlichsten Abarten von Attacken auf die, durch WSDL und
UDDI genau spezifizierten und für den Angreifer leicht evaluierbaren,
Schnittstellen von Web Services, geachtet werden. Viele der oben genannten
Bereiche sind Gegenstand laufender Entwicklung, Forschung und Standardisierung,
wie z.B. SAML, XKMS, XML Encrypton, XML Signature, WS-Security, XACML,
Liberty Alliance Project, http-R, XrML und .NET Passport um nur die Wichtigsten
zu nennen. Eine genaue Beschreibung aller oder auch nur einiger würde
sowohl den Umfang dieser Arbeit sprengen, als auch da eher ein generisches
Bild gezeichnet werden soll und nicht spezifisch auf die Ausprägung
der einzelnen Klassen eingegangen werden soll. Für weitere Vertiefung
ist eine Lektüre der Standards jedoch sicher nützlich.