Was ist XML gleich nochmal und wie wirs’s verwendet?
XML ist im Business-Bereich sehr verbreitet und wird insbesondere als Protokoll viel verwendet. Der Trend bei Neuentwicklungen geht zwar seit Jahren eher weg von XML – hin zu einfacheren Strukturen, aber wie das in der IT so ist, wird uns XML sicherlich noch viele Jahre beglücken.
Bei Web-Services wird SOAP als Protokoll verwendet, und über SOAP werden XML Strukturen versendet. XML hat den Vorteil, dass man es anhand von StyleSheets, die in XSL oder als Schema definiert sind, sehr klar spezifizieren kann. Damit kann man also die Inhalte sehr genau steuern, was bei einer stark typgebundenen Schnittstelle ein großer Vorteil ist.
Der Nachteil dabei ist aber, dass ein XML-Parser jedes Mal das XML-Dokument parsen und interpretieren muss, also auf seine Bestandteile hin überprüfen und die Felder dann in Objekte überführen muss. Das kostet Zeit und ist sehr oft Anfällig für Fehlinterpretationen, weshalb es in vielen Interpretern unzählige Sicherheitslücken gibt. Gute Beispiele dafür sind Flash oder Acrobat.
Problem
XXE ist zunächst mal gar keine Sicherheitslücke, sondern ein Feature von XML 1.0. Mit XXE ist es möglich, auf lokaleInhalte vom Dateisystem, oder auf entfernteInhalte zuzugreifen – meist über weitere Webserver.
Diese Inhalte können dann innerhalb des XML-Dokuments verwendet werden, was an sich eine tolle Sache ist, denn so kann ich (wie auf einer HTML-Seite) Ressourcen einbinden, wie Bilder oder Daten.
![](https://geballte-sicherheit.de/wp-content/uploads/2019/02/Folie01-1024x576.png)
Hier die Definition einer Externen Entität:
- Man deklariert im Header-Bereich der XML-Datei ein Doctype (eine DTD)
- Innerhalb der DTD kann man dann ein Element definieren, über das man später auf die XXE zugreifen kann im XML-Body.
- Dann die Entity definiert, und eine URL angegeben, die dann später vom XML-Parser aufgelöst wird. Der Parser greift dann also tatsächlich auf eine Webseite zu, oder auch aufs lokale Dateisystem, um von dort die Inhalte zu laden.
- Das ist schon die ganze Definition der XXE
- Im XML-Body kann man dann die XXE verwenden, wie gewohnt über das Tag, das man damit definiert hat.
- Das ganze ist wie gesagt kein Bug, sondern eigentlich ein tolles Feature von XML, aber dadurch schafft man halt auch eine potentielle Sicherheitslücken, wenn ein Angreifer so auf sensible Daten Zugriff hat.
Schwachstellen
Der Vorteil dieser Freiheit ist gleichzeitig die Schwachstelle bei der Sicherheit, wenn es nämlich ein Angreifer schafft, auf verborgene Ressourcen zuzugreifen, z.B. um geheime Daten auszuspähen oder sie zu stehlen, oder um Daten zu manipulieren. Außerdem kann man über XXE auch ein DOS-Angriff ausführen, indem man den Interpreter überfordert, der versucht die XXE aufzulösen.
Hier der Ablauf eines typischen Szenarios, wie ein Angreifer Daten abgreifen könnte.
![](https://geballte-sicherheit.de/wp-content/uploads/2019/02/Folie04-1024x576.png)
- Im ersten Schritt wird in einem XML Dokument, das später hochgeladen werden soll, eine XXE definiert.
- diese XXE soll versuchen, auf das Dateisystem des Webservers zuzugreifen und dort den Inhalt der Passwortdatei auslesen
- Diese XML-Datei wird nun hochgeladen zur Webanwendung – Voraussetzung ist natürlich, dass die Webanwendung dafür einen Fileupload zur Verfügung stellt
- Die Webanwendung nimmt das XML Dokument entgegen, der XML Parser parst die Struktur und versucht die XXE aufzulösen. Dazu muss er wie angegeben auf das lokale Dateisystem zugreifen und die /etc/passwd auslesen. Wenn das erfolgreich ist, dann wird genau dieser Inhalt an der Stelle ins XML Dokument eingebettet, wo das Message-Tag verwendet wird.
- Die Antwort wird jetzt je nach Webanwendung entweder dem Angreifer direkt zurückgeschickt, oder in der Anwendung selbst abgelegt, z.B. als Datenfeld in der Datenbank, wo es dann später ausgelesen werden kann
- Ist der UseCase der Anwendung z.B. so, dass mit dem XML Kundendaten ins System importiert werden, dann könnte man diese ergaunerten Daten im Adressfeld oder im Kommentarfeld eines Kunden speichern, und diese später abrufen, wenn man die Adresse des Kunden anzeigen lässt.
Mit XXE kann auch ein Denial-of-Service Angriff gemacht werden. Die Entitäten sind so geschrieben, dass sie sich gegenseitig aufrufen, wenn der XML-Parser versucht, sie aufzulösen. Durch exorbitante Iterationen geht ihm der Speicher aus, so dass er abstürzt und im schlimmsten Fall den Webserver mitreist.
![](https://geballte-sicherheit.de/wp-content/uploads/2019/02/Folie05-1024x576.png)
Auswirkungen
Für eine Webanwendung bedeutet das, dass wir überall wo XML verwendet wird, darauf achten müssen, dass bei der Verwendung von XXE Vorsicht geboten ist. Im B2B-Bereich wird oft mit XML-Uploads gearbeitet, wo XML Dokumente hochgeladen werden können. Oder bei Webservices: dort wird ausschließlich XML gesprochen, also die Anfragen und die Antworten an der Schnittstelle erfolgen ausschließlich über XML.
Wenn dort XXE nicht gebraucht wird, dann sollte man es auch nicht unterstützen und im jeweils zuständigen XML-Parser deaktivieren. Ist das nicht zu 100% möglich, weil man XXE verwendet, dann gibt‘s zum Glück noch andere Sicherheitsmaßnahmen, die man treffen kann.
Wie immer verrate ich Euch einige Tricks aus der Secure Coding Schulung, die Euch helfen sich gegen solche Angriffe zu schützen.
Praxis Tipps
Was kann also getan werden, um XXE-Schwachstellen einzudämmen?
Möglichkeiten zur Konfiguration der XML-Parser gibt‘s mehrere, um bei der Verarbeitung der XML-Dokumente für die Sicherheit zu sorgen.
Tipp 1 fängt mit der restriktivsten Variante an:
- Doctype Declarations (DTDs) verbieten, falls möglich
- Dadurch kann keine DTD mehr verwendet werden, in der eine XXE definiert wird
- Dadurch werden fast alle XXE Angriffe verhindert
Tipp 2:
- Falls DTDs gebraucht werden, XXE zumindest einschränken
- Keine externen DTDs erlauben
- dann können kein externen Inhalte dazugeladen werden
- Keine General Entities und keine Parameter Entities erlauben
- dann können keine XXEs definiert werden
- Keine externen DTDs erlauben
Tipp 3:
- Falls XXE tatsächlich in Eurer Anwendung verwendet werden muss, kann man zumindest das
- „Secure Processing“ aktivieren
- Verhindert DOS, da z.B. Iterationen auf 64k beschränkt werden
- Verhindert Remote File Access
- „Secure Processing“ aktivieren
Allerdings sind die Konfigurationen zu diesen 3 Tipps nicht in allen Fällen auf die gleiche Art und Weise möglich. Deshalb ist es nicht ganz einfach, das allgemeingültig darzustellen.
Es gibt viele verschiedene XML-Parser, die sich unterschiedlich verhalten. In der Java-Welt gibt es allein im JDK7 über 10 XML-Parser für unterschiedliche Zwecke. Außerdem gibt es noch ext. XML-Parser, z.B. DOM4J, SAXBuilder oder mehrere in Spring.
Ihr müsst Euch also wohl oder übel damit beschäftigen, wo in Eurer Anwendung XML verarbeitet wird. Kritisch sind die Stellen, wo von außen XML angenommen wird, also an den Schnittstellen.
Generell gilt also bei XML-Parsern folgende Vorgehensweise:
- API nach Flags untersuchen
- DTD deaktivieren
- Ext. DTD deaktivieren
- Falls nicht möglich:
- XXE deaktivieren
- Secure Processing
- Falls nicht möglich:
Fazit
Der Platz 4 der OWASP Top10 ist deshalb so kritisch, weil viele Anwendungen die XML verarbeiten, überhaupt keine Sicherheitsmaßnahmen aktiviert haben. Durch die Problematik in den XML-Parsern macht sich die Anwendung verwundbar gegenüber externen Entitäten in XML.
Die Folge eines Angriffs kann unberechtigter Zugriff auf Daten sein, deren Manipulation, oder ein Denial-of-Service Angriff.Meist kann das durch Konfiguration der XML-Parser im Quellcode beseitigt werden, wie ich in den Beispielen gezeigt habe. Weitere Tipps zu diesem Thema, sowie Übungen im Workshop biete ich Euch in meiner Secure Coding Schulung.