Security

Sicherheit und Seife

Wie sicher ist SOAP? Und wie kann man es absichern?
Keine Kommentare

SOAP war früher die Abkürzung für Simple Object Access Protocol; heutzutage wird diese aber nicht mehr verwendet, denn SOAP ist gar nicht so „Simple“ und auf keinen Fall nur auf Objektzugriffe beschränkt. Wenn etwas nicht einfach ist, wird es schnell zur Gefahrenquelle: Entweder weil die Implementierungen Schwachstellen aufweisen oder eine sichere Nutzung unnötig erschwert wird. Wie sieht es denn da bei SOAP aus?

SOAP gilt dem Austausch von Daten und dem Durchführen von Remote Procedure Calls (RPC, entfernte Prozeduraufrufe), ursprünglich nur zwischen verschiedenen Servern, inzwischen auch zwischen Client und Server. SOAP stützt sich auf verschiedene andere Standards: XML für die Repräsentation der Daten und Internetprotokolle (vor allem HTTP) für ihren Austausch.

Eins seiner Haupteinsatzgebiete ist die Kommunikation zwischen Webservices, und im Rahmen von Webanwendungen wird es meist für die Kommunikation zwischen verschiedenen Backend-Komponenten verwendet. Aber auch für die Konfiguration von Netzwerkgeräten wird teilweise SOAP für die Kommunikation verwendet.

Einige Beispiele für Schwachstellen und Angriffe

Im November 2016 wurde eine Schwachstelle in den DSL-Routern des irischen Providers Eir gefunden. Die Router öffneten einen Port für das Fernwartungsprotokoll TR-069, der auch für das damit verwandte Protokoll TR-064 genutzt wird. Und das sollte eigentlich nur aus dem lokalen Netz zugänglich sein, da über dessen SOAP-Schnittstelle ohne Authentifizierung die DNS- und NTP-Konfiguration der Geräte geändert werden kann.

2016: Angriff auf Telekom-Router

Nun ist Irland ziemlich weit weg und Schwachstellen in den dortigen DSL-Routern sind hier in Deutschland erst mal ziemlich uninteressant. Aber nur, bis ein Cyberkrimineller versucht, die Schwachstelle auch hier auszunutzen – probieren kann man es ja mal, die Provider bauen und/oder programmieren ihre Router ja nicht selbst, sondern kaufen sie irgendwo ein. Da ist es gar nicht mal so unwahrscheinlich, dass die in mehr als einem Land und/oder von mehr als einem Provider genutzt werden. Wenig später kam es zu einer großflächigen Störung im Telekom-Netz: Ein Cyberkrimineller hatte den Proof of Concept für die Schwachstelle in den irischen Routern mit dem Code des Mirai-Botnets kombiniert und auf das Telekom-Netz losgelassen. Dort kam es allerdings nicht zur Infektion der Router, stattdessen fielen sie aus.

Nicht SOAP, sondern der aus dem Internet zugängliche Port für die Fernwartung war hier das Problem. SOAP diente nur dem Transport des Exploits. So auch im folgenden Beispiel.

2015: Schwachstelle in Netgear-Routern

Im Februar 2015 wurde eine Schwachstelle in Netgear-Routern entdeckt: Die Router stellen ein SOAP-Interface bereit, über das die Webadministrationsoberfläche der Konfigurationssoftware „Genie“ Informationen über das lokale Netzwerk und den Router abfragen kann, wie z. B. Passwörter und den WLAN-Schlüssel. Das Interface sollte auf unberechtigte Anfragen eigentlich mit einem 401-HTTP-Fehler antworten, der Schutz ließ sich allerdings umgehen. Und da das SOAP-Interface auch aus dem Internet zugänglich war, waren Angriffe von dort aus möglich.

2015: Schwachstelle in Windows Server Update Services (WSUS)

Paul Stone und Alex Chapman haben auf der Black Hat USA 2015 unter dem Titel „WSUSpect – Compromising the Windows Enterprise via Windows Update“ Angriffe auf die Windows Server Update Services (WSUS) vorgestellt.

Windows Update dient Microsoft dazu, Updates für Betriebssysteme und Anwendungen zu verteilen. Dazu führen die Windows Update Services in regelmäßigen Abständen das Programm wuauctl.exe aus, das über das Internet bei Windows Update nach neuen Updates für das System und die installierte Hardware fragt. wuauctl.exe wird über Registry-Einträge konfiguriert; z. B. wird so festgelegt, woher Updates heruntergeladen werden, wie oft nach neuen Updates gesucht wird, ob Nicht-Admins höhere Rechte bekommen sollen oder nicht und vieles mehr.

Die Kommunikation zwischen wuauctl.exe und den Windows-Update-Servern erfolgt über einen SOAP Webservice über HTTPS. Beim Fragen nach neuen Updates sendet die Anwendung eine vollständige Liste der installierten Updates an den Windows-Update-Server, der mit einer Liste der verfügbaren Updates antwortet.

Die Windows Server Update Services agieren als Proxy zu Microsofts öffentlichem Windows Update Service. Die WSUS holen die Updates über das Internet vom Windows Update Service und speichern sie lokal. Die Rechner im Intranet holen ihre Updates dann nicht vom öffentlichen Microsoft-Server, sondern vom lokalen WSUS-Server. Die Administratoren haben dadurch eine bessere Kontrolle darüber, wie Updates in ihrem Netz ausgerollt werden.

WSUS verwenden, wie Windows Update auch, SOAP-Aufrufe und die Protokolle sind abgesehen von der Authentisierung identisch.

Per Default verwenden WSUS für den SOAP Webservice kein SSL, sondern normales HTTP über Port 8530. Im letzten Schritt des Installations-Wizards wird der Admin aber aufgefordert, SSL zu konfigurieren. Dazu muss nur ein Zertifikat für den WSUS-Server installiert und die Nutzung von HTTPS für die Suche nach Updates auf den Clients eingeschaltet werden.

Alle von Windows Update heruntergeladenen Updates sind von Microsoft signiert. Vor der Installation der Updates wird die Signatur geprüft, nicht von Windows signierte Pakete werden bei der Nutzung von WSUS zurückgewiesen.

Während die signierten Updatedateien nicht manipuliert werden können, ohne die Signatur ungültig zu machen, kann ein Angreifer die Updatemetadaten nach Belieben manipulieren und sogar Fake-Updates erstellen. Indem ein Angreifer ein Update einschleust, das den CommandLineInstallation-Update-Handler verwendet, kann er den Client dazu bringen, jedes beliebige von Microsoft signierte Programm zu starten, auch wenn es gar nicht dafür vorgesehen war, von Windows Update genutzt zu werden. Außerdem kann er dem Programm beliebige Argumente übergeben. Z. B. sind Microsofts Sysinternals-Tools signiert und das Utility PsExec, mit dem normalerweise Befehle auf entfernten Systemen ausgeführt werden, kann auch verwendet werden, um lokal Befehle als der aktuelle Benutzer auszuführen.

Die beiden Forscher konnten als Man in the Middle (MitM) in einer WSUS-Verbindung ein Update einschleusen, das PsExec verwendet, um über die zugehörigen Metadaten beliebige Befehle auf dem Client auszuführen. Eine ausführlichere Beschreibung finden Sie im Windows Developer 1.17 [1].

Und die Moral von der Geschicht?

„Vergiss Verschlüsselung, Authentifizierung und Autorisierung nicht!“

Für die Transportschicht ist die Lösung des Problems einfach: Statt HTTP muss einfach HTTPS verwendet werden; bei anderen Transportmethoden die dort übliche sichere Variante. Der Nachteil dieser Lösung: Bei der Kommunikation über mehrere Knoten ist keine direkte Ende-zu-Ende-Sicherheit möglich.

XML Encryption und XML Signature

Die lässt sich erreichen, indem nur die XML-Daten verschlüsselt und/oder signiert werden.

Für die Verschlüsselung gibt es die W3C Recommendation „XML Encryption Syntax and Processing“ (XML Encryption). Die definiert eine Reihe von Möglichkeiten, wie XML-Dokumente ver- und entschlüsselt werden können. Für die Verschlüsselung sind folgende Möglichkeiten vorgesehen:

  • Verschlüsselung des gesamten XML-Dokuments
  • Verschlüsselung eines einzelnen Elements und seiner Unterelemente
  • Verschlüsselung des Inhalts eines XML-Elements
  • Verschlüsselung für mehrere Empfänger

Für die Signatur ist die W3C Recommendation „XML Signature Syntax and Processing“ zuständig (XML Signature, auch XMLDsig genannt). Die definiert eine XML-Schreibweise für digitale Signaturen, vergleichbar mit dem PKCS#7-Standard. Mit XML-Signaturen können Daten jedes Typs signiert werden, sofern sie in das XML-Dokument der Signatur eingebettet worden sind oder mit einem URL adressiert werden können. Die Signatur eingebetteter Daten wird als „enveloped signature“ bezeichnet, die verlinkter Daten als „detached signature“.

WS-Security

Speziell zur Absicherung von SOAP-basierten Web-Services gibt es den Standard WS-Security sowie weitere zugehörige WS-*-Standards für Detaillösungen. Darin wird festgelegt, wie die Daten für Web-Services verschlüsselt und signiert werden müssen und wie Securitytoken als Teil der SOAP-Nachricht übertragen werden können. Für die Verschlüsselung und Signatur selbst wird auf die vorhandenen Standards XML Encryption und XML Signature zurückgegriffen.

Die Securitytokens können Benutzername und Passwort, X.509-Zertifikate, Kerberos-Tickets, SAML-Assertions und REL-Tokens sein.

Die Security Assertion Markup Language (SAML) ist ein XML-Framework zum Austausch von Authentifizierungs- und Autorisierungsinformationen; eine Assertion ist eine Aussage über eine erfolgreiche Authentifizierung, Autorisierung oder Attributsprüfung.

Die Rights Expression Language (REL) beschreibt, wie Token nach ISO/IEC 21000-5 („Rights Expressions“) im Rahmen der WS-Security verwendet werden können.

Wozu das Ganze?

Sie haben es sicher schon erkannt: Man kann die Verschlüsselung und Authentifizierung HTTPS übertragen und man kann die XML-Daten der SOAP-Nachrichten einzeln verschlüsseln und/oder signieren, da ist die WS-Security doch eigentlich völlig überflüssig? Ist sie auch, so lange nur zwei Parteien beteiligt sind, z. B. Client und Server oder Server und Web-Services. Sobald aber z. B. der Client mit Webserver und Datenbank kommunizieren muss und zusätzlich der Webserver im Namen des Clients auf die Datenbank zugreifen soll, wird WS-Security nützlich. Und zwar speziell dessen Möglichkeit, ein Securitytoken zu übertragen. Der Client kann sich von einem Tokenserver ein Token ausstellen lassen und damit auf Webserver und Datenbank zugreifen. Und der Webserver kann die SOAP-Nachricht mit dem Token an die Datenbank weiterreichen, um darauf im Namen des Clients zuzugreifen.

Für die Absicherung der übertragenen Daten gibt es also gleich mehrere Möglichkeiten. Für die Authentifizierung der Benutzer ebenfalls. Trotzdem bleibt noch eine potenzielle Schwachstelle übrig.

SOAP Injection

In den OWASP Top 10 mit den zehn gefährlichsten Risiken für Webanwendungen hält sich eine Schwachstelle konstant auf Platz 1: die Injection. Und die gibt es auch als Variante für SOAP.

Da XML interpretiert wird, ist SOAP potenziell anfällig für das Einschleusen von fremdem Code. XML-Elemente werden mithilfe der Metazeichen <, > und / dargestellt. Werden Benutzereingaben, die diese drei Zeichen enthalten, direkt in eine SOAP-Nachricht eingefügt, kann ein Angreifer darüber die Struktur der Nachricht und indirekt die Anwendungslogik beeinflussen. Das Gefährliche daran: Da der Angriff über reguläre Benutzereingaben erfolgt, schützt davor weder eine Verschlüsselung noch eine Signatur der Daten, allenfalls Authentifizierung und Autorisierung grenzen den Kreis möglicher Angreifer ein. Das gilt für Angriffe auf die erlaubten Benutzer und jeden Angreifer, der die Authentifizierung unterlaufen hat.

Ein Beispiel

Eine Onlinebankinganwendung verwendet für Überweisungen einen GET http Request nach folgendem Muster:

http://www.bank.example/ueberweisen.cgi?vonKonto=1234567&aufKonto=9876543&Betrag=123,45

Dass die Kontonummern IBAN sein müssten, ignorieren wir mal, die würden das Ganze nur unübersichtlicher machen. Für die Durchführung der Überweisung wird zwischen zwei Backend-Komponenten die SOAP-Nachricht in Listing 1 verwendet.

<?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 den Wert False hat – 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.

SOAP Injection, zum Ersten…

Ein Angreifer, der die Verwendung und den Aufbau der SOAP-Nachrichten kennt, kann versuchen, über eingeschleusten Code die Programmlogik so zu manipulieren, dass trotz nicht gedeckten Kontos eine Überweisung durchgeführt wird. Der Request

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 in Listing 2.

<#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.

… zum Zweiten …

Eventuell 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>False</Gedeckt></Konto></pre:Add></soap:Body></soap:Envelope><!-- 

Damit ergibt sich die Nachricht in Listing 3.

<#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><!--</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.

Kleine Änderung am Beispiel

Günstiger wäre es, wenn die Elemente in der SOAP-Nachricht eine andere Reihenfolge hätten, z.B. <vonKonto>, <Betrag>, <Gedeckt>, <vonKonto> (Listing 4).

<#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>
        <Betrag>123,45</Betrag>
        <Gedeckt>False</Gedeckt>
        <aufKonto>9876543</aufKonto>
      </Konto>
    </pre:Add>
  </soap:Body>
</soap:Envelope>

In diesem Fall könnte das gefälschte <Gedeckt>-Element über den Parameter Betrag eingeschleust und der Kommentar über den Parameter aufKonto geschlossen werden:

http://www.bank.example/ueberweisen.cgi?vonKonto=1234567&Betrag=123,45</Betrag><Gedeckt>True</Gedeckt><aufKonto><!--&aufKonto= -->9876543

Das ergibt die syntaktisch korrekte SOAP-Nachricht in Listing 5 mit einem geschlossenen Kommentar, durch den das ursprüngliche <Gedeckt>-Element vor der Backend-Anwendung verborgen wird.

<#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>
        <Betrag>123,45</Betrag>
        <Gedeckt>True</Gedeckt>
        <aufKonto>
        <!-- </Betrag><Gedeckt>False</Gedeckt><aufKonto> -->
        9876543</aufKonto>
      </Konto>
    </pre:Add>
  </soap:Body>
</soap:Envelope>

Wie leicht haben es die Angreifer?

SOAP-Injection-Schwachstellen sind schwer zu finden, da falsch eingeschleuste XML-Metazeichen das Format der SOAP-Nachricht zerstören und damit oft nur zu einer allgemeinen Fehlermeldung führen. Hinzu kommt, dass SOAP meist im Backend-Bereich verwendet wird, sodass dort erzeugte Fehlermeldungen oft zusätzlich vom Web-Frontend geändert oder ersetzt werden. Generell können SOAP-Injection-Schwachstellen mit den folgenden Tests erkannt werden:

  • Zuerst wird der Reihe nach in jeden verfügbaren Parameter ein nicht existierendes, schließendes XML-Tag wie z. B. </gibtsnicht> Führt das zu keinem Fehler, wird der betreffende Parameter entweder nicht in einer SOAP-Nachricht eingefügt oder vor dem Einfügen gefiltert.
  • Tritt ein Fehler auf, wird als nächster Test ein gültiges Paar aus öffnenden und schließenden XML-Tags wie z. B. <gibtsnicht></gibtsnicht> Tritt nun kein Fehler mehr auf, enthält die Anwendung sehr wahrscheinlich eine SOAP-Injection-Schwachstelle.

Manchmal werden in eine SOAP-Nachricht eingefügte Parameter nach der Verarbeitung wieder an den Benutzer ausgegeben. Dann kann getestet werden, ob eingegebene XML-Daten unverändert oder in irgendeiner Form normalisiert zurückgegeben werden. Dazu können z. B. folgende Testwerte verwendet werden:

test<gibtsnicht/>
test<gibtsnicht></gibtsnicht>

Werden entweder beide Eingaben unverändert oder nur test zurückgeliefert, wurden sie sehr wahrscheinlich in eine XML-basierte Nachricht eingefügt.

Werden über einen HTTP-Request mehrere Parameter übertragen, die Teil einer SOAP-Nachricht werden könnten, können darüber Kommentarzeichen als Test eingeschleust werden: Über einen der Parameter werden die öffnenden Zeichen <!– eingegeben, über einen anderen die schließenden Zeichen –>. Wird dadurch ein Teil der SOAP-Nachricht auskommentiert, ändert sich entweder das Verhalten der Anwendungslogik oder es gibt vielleicht eine andere Fehlermeldung. Ideal wäre es, wenn statt einer allgemeinen Fehlermeldung eine Meldung wie z. B. „Parameter ‚x‘ fehlt“ weitere Informationen über den Aufbau der SOAP-Nachricht liefert.

Da nicht bekannt ist, in welcher Reihenfolge die Parameter in die SOAP-Nachricht übernommen werden, müssen ggf. alle möglichen Kombinationen ausprobiert werden, bis es zu einem brauchbaren Ergebnis kommt.

SOAP-Injection-Schwachstellen ausnutzen

Es ist schon schwierig genug, SOAP Injection überhaupt zu erkennen. Eine gefundene Schwachstelle dann auch noch auszunutzen ist i. Allg. noch mal deutlich schwieriger. Um die SOAP-Nachricht erfolgreich zu manipulieren, muss ihr Aufbau bekannt sein. Das ist bei Closed-Source-Software wenn überhaupt meist nur durch umfangreiche Tests mit anschließender Auswertung der Fehlermeldungen zu erreichen. Daher freut sich ein Angreifer natürlich besonders über eine ausführliche Fehlermeldung, die gleich die gesamte fehlerhafte SOAP-Nachricht enthält.

SOAP-Injection verhindern

In der Regel ist es, wie wir gesehen haben, eher unwahrscheinlich, dass ein Angreifer eine SOAP-Injection-Schwachstelle in Ihrer Webanwendung findet und erfolgreich ausnutzt. Trotzdem sollten Sie natürlich dafür sorgen, dass es keine gibt. Denn Sie wissen ja: Im Zweifelfalls sorgt Murphys Gesetz dafür, dass ausgerechnet Ihre Webanwendung diejenige ist, die die Ausnahme bestätigt.

Wie immer in solchen Fällen gilt: Um das Einschleusen von Code zu verhindern, müssen alle Daten vor ihrer Übernahme in eine SOAP-Nachricht geprüft, bereinigt und/oder verworfen werden. Das betrifft alle vom Benutzer manipulierbaren Daten, egal ob es sich um direkte Eingaben oder um zuvor gespeicherte und/oder bearbeitete Daten handelt.

XML-Metazeichen müssen in die entsprechenden HTML-Entities umgewandelt werden, sodass der XML Interpreter sie als Daten des betreffenden Elements und nicht als Teil der Nachrichtenstruktur interpretiert. Das betrifft insbesondere < (<), > (>) und / (/).

Wie Sie am Beispiel sehen konnten, kann auch der Aufbau der SOAP-Nachricht sowie deren Interpretation einen Angriff erleichtern oder erschweren. Auch wenn bösartige Eingaben niemals bis in die SOAP-Nachricht gelangen sollten, schadet es nicht, sich bei ihrer Konstruktion Gedanken darüber zu machen, ob und wie Benutzereingaben von selbst erzeugten Daten getrennt werden können.

Manipulation des SOAPAction-Headers

SOAP HTTP(S) Requests können über den SOAPAction-Header die gewünschte Aktion auswählen. Ein MitM kann diesen Wert ändern, muss dann aber meist auch den Body entsprechend anpassen. Das ist nur kritisch, wenn ein authentifizierter Benutzer angegriffen wird, denn beliebige Requests kann der Angreifer selbst schicken. Außerdem sollten Sie ja möglichst HTTPS nutzen und/oder die XML-Daten verschlüsselt und/oder signiert übertragen.

Im Fall von HTTPS hat der Angreifer im Allgemeinen keine Möglichkeit, den Header zu manipulieren. Ein MitM-Angriff auf HTTPS ist zwar prinzipiell möglich, aber ziemlich aufwendig.

Wird der XML-Body verschlüsselt und/oder signiert, kann ein MitM die Daten darin nicht bzw. nicht unbemerkt an seinen geänderten SOAPAction-Header anpassen und ein Angriff scheitert an den nicht passenden Daten bzw. ist auf Aktionen beschränkt, bei denen die Originaldaten verwendet werden können.

Fazit

SOAP ist nicht zwingend simpel und XML Encryption und XML Signature machen das Ganze nicht einfacher, von WS-Security ganz zu schweigen. Wenn Sie sich die vorgestellten Beispielschwachstellen und -angriffe ansehen, erkennen Sie aber das Muster: Das Problem ist nicht SOAP selbst, sondern die fehlende Authentifizierung bzw. Autorisierung. Oder die unzureichende Prüfung der darüber erhaltenen Daten, wie eine Suche nach „SOAP“ in der CVE-Datenbank zeigt. Diese Schwachstellen wären auch entstanden, wenn die Entwickler REST statt SOAP in gleicher Weise verwendet hätten.

Ab und zu gibt es Probleme mit den SOAP-Implementierungen, aber die sind ziemlich selten. Auch auf den Sicherheitskonferenzen wurden in den letzten Jahren keine Schwachstellen in bzw. Angriffe auf SOAP selbst vorgestellt; das Protokoll sowie seine Implementierungen sind also wohl relativ sicher. Möglicherweise aber nur, weil die Sicherheitsforscher vielleicht auch nur keine Lust haben, sich damit zu befassen.

Die größten Probleme bei SOAP sind aber tatsächlich Authentifizierung und Prüfung der darüber erhaltenen Daten. Wenn Sie die Daten aus einem SOAP Request ungeprüft für z. B. eine SQL-Abfrage verwenden, erhalten Sie sofort eine wunderschöne SQL-Injection-Schwachstelle. Aber die hat nichts mit SOAP zu tun, sondern mit der fehlenden Prüfung der Eingaben.

Und da gibt es bei SOAP auch den einzigen Punkt, den Sie zusätzlich beachten müssen: Bevor Sie Benutzereingaben in einen SOAP-Request übernehmen, müssen Sie sie so kodieren, dass sie den Request nicht manipulieren können.

Alles andere ist für Webanwendungen und Web-Services „Business as usual“; z. B. führt eine fehlerhafte Authentifizierung immer zu Problemen. Egal ob Sie SOAP oder REST verwenden, ob Sie die Daten per HTTP, HTTPS oder Brieftauben übertragen, ob der Server mit Windows oder Linux läuft usw.

 

Links & Literatur

[1] Eilers, Carsten: „Ist es ein Update oder ein Schädling?“ in: Windows Developer 1.17

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -