SOAP definiert Struktur der XML-Nachrichten für eine Maschine-zu-Maschine-Kommunikation (M2M Communication). Die SOAP-Nachrichten sind in der Regel mit zwei Elementen gekennzeichnet: Header und Body. Das Header-Element enthält nachrichtenspezifische Daten wie z. B. Zeitstempel oder Sicherheitstoken. Das Body-Element enthält einen Funktionsaufruf und wird vor allem auf die Geschäftslogik des Empfängers gerichtet.

Das Bild zeigt die Kommunikation zwischen einem Webservice-Client und einem Server. Der Client schickt an den Server eine SOAP-Nachricht, die einen Funktionsaufruf CreateUser enthält. Wenn der Server diese Nachricht empfängt, interpretiert dieser zuerst den Funktionsnamen und den Funktionsparameter im Body-Element. Danach führt er die Funktion aus. Am Ende erstellt er eine SOAP-Nachricht, die über den Status des Aufrufs berichtet. Diese Nachricht schickt er an den Client.

Der nächste in diesem Artikel betrachtete Standard ist SAML. Die Motivation für die Standardisierung von SAML war ein typisches Passwort-Identität-Problem. Aus dem eigenen, täglichen Internetleben kennt jeder das Problem, im Internet viele Identitäten auf verschiedenen Internetwebseiten zu verwenden und zu verwalten. Damit sich der Benutzer nicht alle Passwörter zu seinen Identitäten merken muss, wurde Single Sign-On entwickelt. Single Sign-On stellt ein Konzept vor, bei dem sich der Benutzer nur einmalig bei einem Identity Provider mit seinem Passwort anmeldet. Der Identity Provider erstellt nachträglich für den Benutzer sogenannte Tokens, die er bei Webseiten (Service Providern) einlösen kann.

In Abb.2 ist ein Benutzer (Bob) dargestellt, der sich auf seiner Webseite einloggen möchte (z. B. Salesforce). Wenn er die Webseite mit seinem Browser besucht, wird er zu seinem Identity Provider weitergeleitet (z. B. Onelogin). Der Identity Provider erstellt für den Benutzer ein signiertes SAML-Token. Mit diesem Token wird der Benutzer wieder zu Salesforce weitergeleitet und dort eingeloggt.

Für den weiteren Verlauf des Artikels müssen wir uns merken, dass bei einem SAML-basierten Single Sign-On XML-basierte SAML-Token eingesetzt werden. Das Token beinhaltet Informationen über den Benutzer und Ablaufdatum. Damit das Token nicht manipuliert wird, wird es vom Identity Provider signiert.

Im Folgenden fangen wir mit dem spannenden Teil an und präsentieren die ersten Angriffe. Wir starten dabei mit dem XML-Parsing-Prozess.

Um eine eingehende SOAP-Nachricht oder SAML-Nachricht bearbeiten und beantworten zu können, muss diese zuerst geparst werden. XML-Parsing ist ein Prozess, der einen Bytestrom in eine Baum-Struktur übersetzt. Zum Beispiel sieht die oben vorgestellte Nachricht nach dem Parsing-Prozess in einer Baum-Struktur wie in Abb.3 dargestellt aus. Der Server kann diese geparste Struktur sehr einfach bearbeiten, da er auf alle Elemente problemlos zugreifen kann. Allerdings können schon beim Parsing-Prozess die ersten Probleme auftreten.

DoS-Angriffe zielen auf die Verfügbarkeit der Server und der darauf laufenden Dienste ab. Wenn ein Dienst nicht verfügbar ist, können damit dem Betreiber große Schäden verursacht werden. Natürlich können Angreifer mit mächtigen Ressourcen DoS-Angriffe (fast) immer ausführen. Mit XML kann aber ein solcher Angriff auch ohne viel Ressourcenaufwand ermöglicht werden. Der erste (und einfachste) vorgestellte Angriff heißt Coercive Parsing [2]. Der Angreifer erstellt dabei eine XML-Nachricht, welche viele verschachtelte Elemente beinhaltet (s. Abb.4).

Das Problem bei Coercive Parsing liegt darin, dass der Angreifer lediglich wenige Bytes senden muss. Der Server muss jedoch für jedes XML-Element einen Speicherbereich im Arbeitsspeicher des Servers reservieren und zusätzlich zu den offensichtlichen Informationen (z. B. den Namen des Elements) weitere Informationen abspeichern (z. B. eine Referenz auf das Elternelement, Referenzen auf alle Kindelemente, usw.). Dies benötigt wesentlich mehr Speicherplatz als die reine Abspeicherung eines XML-Dokuments in seiner reinen Byteform.

Gegenmaßnahmen: Ähnliche Angriffe können auch mit wiederholenden Attributen oder langen Elementnamen erzielt werden [2]. Daher ist die beste Gegenmaßnahme, die Länge der Nachricht explizit einzugrenzen. Falls dies nicht möglich ist, wird es empfohlen, die Anzahl der Elemente und Attribute und die Baum-Tiefe direkt beim Einlesen zu überprüfen.

Eins der größten Ziele von XML war ihre Flexibilität, damit diese Sprache in allen möglichen Szenarien eingesetzt werden kann. Daher beinhaltet XML auch bestimmte Erweiterungen, die heutzutage sehr selten gebraucht werden. Eine dieser Erweiterungen ist Document Type Definition (DTD). DTD erlaubt es, XML-Bausteine zu definieren. Diese Bausteine können direkt in der XML-Datei definiert werden, sie können aber auch aus einer externen Datei kommen. Also mit DTD kann ein Parser gezwungen werden, externe Inhalte einzulesen. Damit ist DTD auch zu einem der wichtigsten Bestandteile zahlreicher Angriffe geworden, die XXE genannt werden. Für ihre Beschreibung betrachten wir Abb.5. Der Server aus der Abbildung akzeptiert Bestellungen über einen Webservice. Bei jeder erfolgreichen Anfrage antwortet der Server mit einer Nachricht, die den Namen des Bestellers beinhaltet.

Jetzt stellen wir uns vor, der Angreifer (Client) definiert in seiner Nachricht eine XML-Entität name, die auf die System-Datei "c:\boot.ini" verweist. Er referenziert die Entität in der XML-Nachricht mit &name;. Wenn der Server diese Nachricht bearbeitet, versucht er die definierte Entität aufzulösen. Dabei liest er den Inhalt der Datei "c:\boot.ini" aus. Anschließend antwortet er dem Angreifer mit einer Nachricht, die den kompletten Dateiinhalt enthält.

Gegenmaßnahmen: Die Gegenmaßnahme gegen diesen Angriff scheint sehr trivial zu sein: man muss DTDs verbieten. Jedoch erfreuen sich XXE-Angriffe in den letzten Jahren einer großen Beliebtheit und tauchen immer wieder in Schlagzeilen auf. Der Grund dafür ist, dass dieses Feature in den üblichen XML-Parsern standardmäßig aktiviert ist. Wenn es von Entwicklern nicht bewusst ausgeschaltet wird, kann es zu diesen schwerwiegenden Angriffen kommen.

Der SOAP-Standard enthält auch einige vergessene Erweiterungen, die ein Angreifer ausnutzen könnte. In der Mehrheit der Webservice-Szenarien sind diese Erweiterungen aber nicht für den eigentlichen Zweck des Webservices notwendig. Eine dieser Erweiterungen ist WS-Addressing.

WS-Adressing ist eine SOAP-Erweiterung, die eine Weiterleitung von SOAP-Nachrichten ermöglicht: In einem Header-Element kann der Client definieren, wohin seine Anfrage oder die Antwort des Servers weitergeleitet werden soll. Wenn der Server diese Erweiterung tatsächlich unterstützt und die Eingaben nicht korrekt filtert, kann ein Angreifer den Server zwingen, beliebige Nachrichten an beliebige Server weiterzuleiten (s. Abb.6).

In der Abbildung sehen wir einen Client, der von außen nur Zugriff auf den Server A hat. Den Server B kann er von außen nicht erreichen. Er möchte aber seine Nachrichten an diesen Server schicken. Dies kann er damit erzielen, in dem er ein neues To-Element definiert, das die Adresse von Server B beinhaltet. Wenn so eine Anfrage am Server A ankommt, wird sie an den Server B weitergeleitet. So kann der Angreifer beispielsweise einen DoS-Angriff direkt auf den Server B ausführen. Eine weitere Möglichkeit ist es, dass der Angreifer mehrere SOAP-Nachrichten mit unterschiedlichen Adressen an den Server A schickt. Damit kann er die interne Netzwerkinfrastruktur und IP-Adressen scannen. Dieser Angriff wird auch WS-Addressing Spoofing genannt [2].

Gegenmaßnahmen: In einigen Frameworks ist WS-Addressing leider standardmäßig aktiviert. Daher empfehlen wir immer explizit zu überprüfen, ob dieses Feature aktiviert ist und es ggf. abzuschalten.

Signierte Nachrichten Richtig Fälschen: mit XML Signature Wrapping

XML-Signaturen erlauben es, beliebige Inhalte zu signieren und damit die Authentizität und Integrität zu schützen. Im Folgenden werden wir XML Signature Wrapping (XSW)-Angriffe [4] vorstellen, welche es ermöglichen, signierte Dateien zu modifizieren.

XML Signatur [3] definiert die Syntax und Regeln für die Erstellung und Überprüfung von XML-basierten digitalen Signaturen. Die Spezifikation ist sehr flexibel. Sie ermöglicht es, die ganze XML-Struktur, spezifische Elemente oder sogar nur den Inhalt eines Elementes zu signieren. Eine vereinfachte Struktur einer Signatur angewandt an unsere SOAP-Nachricht ist in Abb.7 skizziert.

Die dargestellte SOAP-Nachricht enthält einen "CreateUser"-Funktionsaufruf im Body-Element. Im Header-Element befindet sich die Signatur. Sie besteht aus zwei Elementen: SignedInfo und SignatureValue. In SignedInfo befindet sich eine Id-basierte Referenz auf das Body-Element. Über das Body-Element wurde ein Hash berechnet, der im DigestValue-Element gespeichert wird. Damit wird gewährleistet, dass das Body-Element nicht verändert wird. Um das SignedInfo-Element zu schützen, wird eine Signatur über das gesamte SignedInfo-Element berechnet (z. B. mit RSA) und im SignatureValue-Element gespeichert.

Validierung einer XML-Signatur ist ein komplexer Prozess. Es besteht aus einer Id-basierten Dereferenzierung, XML-Kanonisierung, zweistufiger Hashwert-Berechnung und Auswertung einer Signatur. Auf der anderen Seite kann die Suche nach einer Funktion im Body-Element mit einem XML-Parser einfach umgesetzt werden. Dies führt dazu, dass Dokumente mit XML-Signaturen in der Regel in zwei Schritten bearbeitet werden: Signaturvalidierung und Funktion-Ausführung (Geschäftslogik). Die Signaturvalidierungslogik wird typischerweise als eine eigenständige Bibliothek implementiert oder mit einer XML-Firewall umgesetzt. Die Geschäftslogik wird von dem Benutzer implementiert.

Wenn Dokumente in zwei unabhängigen Schritten bearbeitet werden, besteht die Gefahr durch XSW-Angriffe. Ziel des Angreifers ist es dabei, die Nachricht so zu verändern, dass die Signaturvalidierung und die Geschäftslogik auf unterschiedliche Elemente zugreifen. Betrachten wir dafür folgende Nachricht (s. Abb.8).

Nehmen wir an, dass der Angreifer eine signierte Nachricht abgefangen hat, mit welcher ein neuer Benutzer erstellt wird. Sein Ziel ist es, eine andere Funktion auszuführen, so dass er Admin-Rechte kriegt. Er geht dabei wie folgt vor. Zuerst erstellt er ein Wrapper-Element in einem Nachrichten-Teil, der von der Geschäftslogik nicht benutzt wird, z. B. im Header-Element. Danach kopiert er das signierte Body-Element mit seinem Inhalt in das Wrapper-Element. Da das verschobene Body-Element immer noch dereferenziert werden kann (das Id-Attribut ist gleich geblieben) und da es auch valid ist (der Hashwert über dieses Element ist gleich geblieben), kann es von der Signaturlogik immer noch erfolgreich validiert werden. Damit hat sich der Angreifer einen Platz für ein neues Element erschaffen. Er kann also ein neues Body-Element mit einer neuen Funktion AddAdminRights hinzufügen.

Diese Nachricht wird anschließend auf dem Server wie folgt verarbeitet: Der Server validiert zuerst die Signatur über das Element mit Id="body". Obwohl dieses Element momentan im Header-Element steht, kann es erfolgreich validiert werden. Anschließend evaluiert die Geschäftslogik das SOAP-Body-Element. Die Geschäftslogik findet hier die Funktion AddAdminRights und führt diese aus. Damit hat sich der Angreifer Admin-Rechte zugeteilt.

Gegenmaßnahmen: Es existieren mehrere Methoden, XSW-Angriffe zu verhindern. Welche Methode am besten geeignet ist, hängt vom Szenario und den eingesetzten Bibliotheken ab. Grundsätzlich muss aber mit der eingesetzten Gegenmaßnahme gewährleisten sein, dass die Signaturvalidierung und die Geschäftslogik dieselben Daten bearbeiten [5, 6, 7].

Die Evaluierung des Webservices besteht aus drei Phasen. In der ersten Phase laden wir mit WS-Attacker die WSDL-Datei. Damit weiß WS-Attacker, wohin die SOAP-Nachrichten geschickt werden sollten und welche SOAP-Version der Webservice unterstützt. Anschließend schicken wir an den Webservice die zur Verfügung stehende SOAP-Nachricht. Somit haben wir WS-Attacker initialisiert. In der zweiten Phase fahren wir mit der Konfiguration der Angriffe fort. Wie in Abb.9 zu sehen ist, haben wir uns für WS-Addressing Spoofing, einige DoS-Angriffe und den XSW-Angriff entschieden.

Die meisten der ausgewählten Angriffe sind automatisch vorkonfiguriert und direkt einsatzbereit.

Bei dem XSW-Angriff müssen wir lediglich den neuen Payload definieren (hier: "Hello attack"), mit dem der originale Payload ersetzt werden soll. In der letzten Phase können wir die eingestellten Angriffe ausführen. Nach kurzer Zeit können wir sehen, dass der getestete Webservice auf den vorgestellten XSW-Angriff und drei DoS-Angriffe anfällig ist (s. Abb.10).