Skip to content

XML-Sicherheit, Teil 6: XPath Injection

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.

Jetzt fehlt nur noch ein Angriff auf bzw. über XML: Die

XPath Injection

XPath ist für XML-Dateien das, was SQL für (SQL-)Datenbanken ist: Für einen Entwickler die Sprache zur Abfrage von Daten, für einen Angreifer ein Einfallstor.

Werden Benutzereingaben ungeprüft für XPath-Abfragen verwendet, kommt es zur XPath Injection: Ein Angreifer kann die Abfrage nach seinen Wünschen manipulieren und unbefugt auf Daten zugreifen. Die XPath-Injection ist ebenso wie die XML-Injection indirekt als Injection Bestandteil der OWASP Top 10 2017. Und zwar auf Platz 1: Top 10-2017 A1-Injection.

Eine XPath Injection hat für den Angreifer einen großen Vorteil gegenüber SQL Injection: Mit XPath kann auf nahezu jeden Teil des XML-Dokuments zugegriffen werden, es gibt keine Zugriffskontrollen mit verschiedenen Benutzern und Rechten. Während bei einem Angriff über SQL Injection das Ergebnis von den Rechten des aktuellen Benutzers abhängig ist, kann bei einem Angriff über XPath Injection immer das gesamte XML-Dokument ausgespäht werden.

Ein Beispiel für einen Angriff

Als Beispiel soll eine Webanwendung dienen, deren Benutzerdaten in einem XML-Dokument gespeichert sind. Die Benutzerdaten bestehen aus Elementen mit dem Namen 'benutzer', die jeweils die 3 Sub-Elemente 'name', 'passwort' und 'userid' enthalten.

Mit der Abfrage

string(//user[name/text()='joe' and passwort/text()='qwertz']/userid/text())

erhält man die User-ID des Benutzers mit dem Namen joe und dem Passwort qwertz.

Diese Abfrage kann auch verwendet werden, um die User-ID eines beliebigen Benutzers zu ermitteln, wobei Name und Passwort direkt aus den Eingaben des Benutzers übernommen werden. Ein Angreifer kann nun z.B. als Namen

' or 1=1 or ''='

eingeben, wodurch die Semantik der ursprünglichen XPath-Abfrage so geändert wird, das immer die erste User-ID ausgegeben wird. Der Angreifer kann sich so als Benutzer mit der ersten User-ID einloggen.

Wie bei einer SQL-Injection sind auch bei einer XPath-Injection weitere Angriffe möglich. Wird das Ergebnis der XPath-Abfrage nicht ausgegeben, kann der Angreifer analog zu einer Blind SQL-Injection eine 'Blind XPath-Injection' durchführen, mit der sich Schrittweise das gesamte XML-Dokument ermitteln lässt.

XPath Injection verhindern

Für den Schutz vor XPath Injection gelten im Grunde die gleichen Maßnahmen wie für den Schutz vor SQL Injection: Die Verwendung parametrisierter Abfragen und die Filterung der Eingaben.

Im Gegensatz zu den meisten Datenbanken kennt XPath selbst keine parametrisierten Abfragen, sie werden aber von verschiedenen APIs wie zum Beispiel XQuery bereitgestellt. Sofern verfügbar, sind sie der beste Schutz vor XPath-Injection und sollten verwendet werden.

Stehen parametrisierte Abfragen nicht zur Verfügung, müssen alle Benutzereingaben geprüft und unerwünschte Eingaben verworfen oder gefiltert werden. Wobei beim Ausfiltern gefährlicher Zeichen wie immer die Gefahr besteht, dass die Filter ausgetrickst werden können.

Am besten wird die Eingabe anhand einer Whitelist mit zulässigen Werten geprüft. Ist das nicht möglich, kann evtl. eine Whitelist zulässiger Zeichen verwendet werden, die am besten nur alphanumerische Zeichen enthält. Als letzte Möglichkeit bleibt das Prüfen auf die gefährlichen Zeichen, über die die XPath-Abfrage manipuliert werden kann. Diese müssen ausgefiltert werden.

Potenziell gefährlich sind folgende Zeichen:

(      )      [      ]
=      :      '     ,
*      /

Außerdem alle Whitespace-Zeichen wie Leer- und Tabulatorzeichen

Und damit ist das Thema XML-Sicherheit zumindest vorerst abgeschlossen. Wobei ich einen Punkt ausgelassen habe: Auch XSS-Angriffe sind über XML möglich. Aber die habe ich hier im Blog schon behandelt.

Mit welchem Thema es nächste Woche weiter geht habe ich noch nicht endgültig entschieden.

Carsten Eilers

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

Trackbacks

Keine Trackbacks