Samstag, 17. April 2010


Topthema

Donnerstag, 29. Januar 2009 | Topthema

About Security #190: Schwachstellen-Suche: SOAP-Injection

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/047096)

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.

Ein Beispiel

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.

Code einschleusen
About Security: Die komplette Serie

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.

Noch ein Versuch

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!

Carsten Eilers

Kommentare

Folgende Links könnten Sie auch interessieren