Skip to content

XML-Sicherheit, Teil 5: XSL Injection, zum zweiten

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.

Weitere mögliche Angriff erfolgen auf bzw. über Extensible Stylesheet Language Transformations (XSLT). Und darüber lassen sich z.B. auch

Schwachstellen im XSLT-Prozessor ausnutzen

Einige Schwachstellen und mögliche Angriffe darauf hat Fernando Arnaboldi auf der BlackHat USA 2015 vorgestellt.

Er hat auf dem Server (sowohl in Stand-Alone Kommandozeilentools als auch in von Programmen genutzten Libraries) und auf den Clients (nur in Webbrowsern, XML/XSLT-Editoren wurden nicht untersucht) nach Schwachstellen in den XSLT-Prozessoren gesucht. Dabei hat er folgende Programme 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 Chrome v43.0.2357.124
  • Internet Explorer v11
  • Opera v30.0
  • Safari v8.0.6

Dabei gibt es die folgenden drei Wege und damit auch Angriffsvektoren für den Einsatz von XSLT:

  1. Ein XML- oder XHTML-Dokument verwendet ein XSLT-Dokument
  2. Ein XML- oder XHTML-Dokument verweist auf ein XSLT-Dokument
  3. Ein XML- oder XHTML-Dokument enthält ein eingebettetes XSLT-Dokument

Übrigens gibt es gar nicht so viele unterschiedliche XSLT-Prozessoren, wie man denken könnte: xsltproc, PHP, Python, Perl, Ruby, Safari, Opera und Chrome verwenden alle libxslt für die Umwandlung. Der Unterschied zwischen Client- und Server-Implementierung besteht nur in der Unterstützung von JavaScript auf dem Client.

Es gibt da ein paar kleine Fehler...

Bei seiner Fehlersuche hat Fernando Arnaboldi folgende Probleme entdeckt:

  • Mit Zahlen umgehen können die XSLT-Prozessoren nicht gerade gut. Bei Fließkommazahlen neigen sie dazu, sich zu verrechnen, und bei Integer-Werten werden aufgrund verschiedener Darstellungsarten unterschiedliche Ergebnisse ausgegeben. Wenn Sie auf korrekte Werte angewiesen sind, müssen Sie einen passenden XSLT-Prozessor wählen.
  • Bei der Erzeugung von Zufallszahlen sieht es auch nicht besser aus. Zum einen sind sie sowieso nur Pseudo-Zufällig, zum anderen wird in libxslt auf die Initialisierungsvektoren verzichtet, so dass die erzeugten Zufallszahlen vorhersagbar sind. Für kryptographische Zwecke sind die Zufallszahlen generell ungeeignet, für andere Zwecke muss bei Verwendung von libxslt bei jedem Aufruf ein anderer Initialisierungsvektor verwendet werden.
  • In Browsern wird teilweise die Same Origin Policy verletzt:
    • Safari erlaubt den Zugriff auf Cross-Origin Informationen
    • Der Internet Explorer zeigt eine Warnung an, empfängt die Cross-Origin Daten, gibt aber keine Informationen aus
    • Chrome, Firefox und Opera empfangen keine Daten
  • Teilweise erlauben Fehler das Lesen von Dateien und damit das Ausspähen von Informationen

Ein Angreifer, der entweder XML- oder XSLT-Datei manipulieren kann, kann diese Fehler sowie die normalen XSLT-Funktionen unter Umständen ausnutzen, um die Sicherheit des die Dateien verarbeitenden Systems kompromittieren.

Schutz vor XSLT-Angriffen

Generell sollten keine fremden Stylesheets verarbeitet werden. Es gibt wohl kaum Anwendungsfälle, in denen der Benutzer zwingend ein eigenes Stylesheet zu seinen Daten mitliefern muss. Außerdem sollten wie überall 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.

Jetzt fehlt nur noch ein Angriff über XML: Die XPath Injection. Und um die geht es in der nächsten Folge.

Carsten Eilers

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

Trackbacks

Dipl.-Inform. Carsten Eilers am : XML-Sicherheit, Teil 6: XPath Injection

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