Mittwoch, 8. Februar 2012 |
SOAP-Injection bzw. das Einschleusen eigenen Codes in SOAP ist das Thema dieser Folge.
SOAP, das Simple Object Access Protocol, dient dem Austausch von Daten und dem Durchführen von Remote Procedure Calls (RPC, entfernte Prozedur-Aufrufe) zwischen verschiedenen Servern. SOAP stützt sich auf verschiedene andere Standards: XML für die Repräsentation der Daten und Internet-Protokolle für ihren Austausch. Sein Haupteinsatzgebiet ist die Kommunikation zwischen Webservices, und im Rahmen von Browsergesteuerten Webanwendungen wird es meist für die Kommunikation zwischen verschiedenen Backend-Komponenten verwendet. Dabei können z.B. verschiedene Teile der Anwendung zur Performancesteigerung auf verschiedene Rechner verteilt oder eine vorhandene Anwendung um ein Web-Frontend erweitert worden sein.
Da XML interpretiert wird, ist SOAP potentiell für das Einschleusen
fremden Codes anfällig. XML-Elemente werden mit Hilfe der Meta-Zeichen
<, > und / dargestellt. Werden
Benutzereingaben, die diese drei Zeichen enthalten, direkt in eine
SOAP-Nachricht eingefügt, kann der Angreifer darüber die Struktur
der Nachricht und indirekt die Anwendungslogik beeinflussen.
Eine Onlinebanking-Anwendung verwendet für Überweisungen einen GET-HTTP-Request nach folgendem Muster:
http://www.bank.example/ueberweisen.cgi?vonKonto=1234567&aufKonto=9876543&
Betrag=123,45
(eigentlich fehlt mindestens die Bankleitzahl des Ziels, aber die würde das Beispiel nur unnötig aufblähen)
Für die Durchführung der Überweisung wird zwischen zwei Backend-Komponenten folgende SOAP-Nachricht gesendet:
<?xml version="1.0" ?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope">
<soap:Body>
<pre:Add xmlns:pre="http://ziel.example/liste
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<Konto>
<vonKonto>1234567</vonKonto>
<aufKonto>9876543</aufKonto>
<Betrag>123,45</Betrag>
<Gedeckt>False</Gedeckt>
</Konto>
</pre:Add>
</soap:Body>
</soap:Envelope>
Die XML-Elemente der SOAP-Nachricht entsprechen den Parametern des
GET-Requests, außerdem gibt es ein Element
<Gedeckt>, das in diesem Fall False ist -
auf dem Konto des Auftraggebers ist nicht genug Geld vorhanden, um die
Überweisung durchzuführen. Der Empfänger der Nachricht
reagiert darauf, indem er die Überweisung nicht durchführt.
Ein Angreifer, der die Verwendung und den Aufbau der SOAP-Nachrichten kennt, kann versuchen, über eingeschleusten Code die Programmlogik so zu manipulieren, das trotz nicht gedeckten Kontos eine Überweisung durchgeführt wird:
http://www.bank.example/ueberweisen.cgi?vonKonto=1234567&aufKonto=9876543&
Betrag=123,45</Betrag><Gedeckt>True</Gedeckt><Betrag>123,45
führt zur SOAP-Nachricht
<?xml version="1.0" ?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope">
<soap:Body>
<pre:Add xmlns:pre="http://ziel.example/liste
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<Konto>
<vonKonto>1234567</vonKonto>
<aufKonto>9876543</aufKonto>
<Betrag>123,45</Betrag>
<Gedeckt>True</Gedeckt>
<Betrag>123,45</Betrag>
<Gedeckt>False</Gedeckt>
</Konto>
</pre:Add>
</soap:Body>
</soap:Envelope>
Verwendet die Anwendung das erste gefundene
<Gedeckt>-Element, wird die Überweisung trotz nicht
gedeckten Kontos ausgeführt. Wird das letzte gefundene
<Gedeckt>-Element verwendet, kann der beschriebene
Angriff nicht zum Erfolg führen, da nur in die
<vonKonto>-, <aufKonto>- und
<Betrag>-Elemente Daten eingefügt werden
können - hinter das vorhandene <Gedeckt>-Element
kann kein Code eingeschleust werden.
Evtl. ist es möglich, durch Auskommentieren eines Teils der vorhandenen Elemente zum Ziel zu kommen. In diesem Fall ist das schwierig, die einzige Möglichkeit besteht darin, die SOAP-Nachricht zu vervollständigen und am Ende einen öffnenden Kommentar einzufügen:
http://www.bank.example/ueberweisen.cgi?vonKonto=1234567&aufKonto=9876543&
Betrag=123,45</Betrag><Gedeckt>True</Gedeckt></Konto></pre:Add></soap:Body>
</soap:Envelope><!--
Damit ergibt sich die Nachricht
<?xml version="1.0" ?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope">
<soap:Body>
<pre:Add xmlns:pre="http://ziel.example/liste
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<Konto>
<vonKonto>1234567</vonKonto>
<aufKonto>9876543</aufKonto>
<Betrag>123,45</Betrag>
<Gedeckt>True</Gedeckt>
</Konto>
</pre:Add>
</soap:Body>
</soap:Envelope><!--</Betrag>
<Gedeckt>False</Gedeckt>
</Konto>
</pre:Add>
</soap:Body>
</soap:Envelope>
Da der Kommentar nicht geschlossen wird, ist die Nachricht syntaktisch falsch und wird von den meisten XML-Interpretern verworfen - der Angriff schlägt also fehl.
Weitere Möglichkeiten für einen Angriff werden in der nächsten Folge beschrieben. Darin erfahren Sie auch, wie Sie die Schwachstellen finden und verhindern können.
Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!