Coders Conquer Security: Serie "Teilen & Lernen" - XML-Injektionen

XML-Injection-Angriffe sind fiese kleine Exploits, die von Hackern erfunden wurden, um Systeme zu kompromittieren, die XML-Datenbanken hosten. Dazu gehören die Dinge, die einem in den Sinn kommen, wenn man an traditionelle Datenbanken denkt - detaillierte Informationsspeicher über alles Mögliche, von Medikamenten bis zu Filmen. Einige XML-Datenspeicher werden auch dazu verwendet, autorisierte Benutzer zu überprüfen, sodass durch das Einfügen von neuem XML-Code in diese Datenbanken neue Benutzer erstellt werden können, die das Host-System von diesem Zeitpunkt an akzeptiert.

Damit ein Angreifer eine XML-Injection implementieren kann, muss eine Anwendung vorhanden sein, die auf eine XML-Datenbank angewiesen ist oder zumindest darauf zugreift. Immer wenn dies der Fall ist und die Benutzereingaben nicht ordnungsgemäß überprüft werden, kann dem Datenspeicher neuer XML-Code hinzugefügt werden. Je nach Geschick des Angreifers kann das Hinzufügen von neuem XML-Code ziemlich viel Schaden anrichten oder sogar Zugriff auf die gesamte Datenbank ermöglichen.

Wenn Sie weiter lesen, werden Sie feststellen, dass XML-Injection eng mit den SQL-Injection-Angriffen verwandt ist, die wir zuvor behandelt haben. Denn obwohl sie auf unterschiedliche Arten von Datenbanken abzielen, sind sie sich extrem ähnlich. Und zum Glück sind auch die Abhilfemaßnahmen ähnlich. Wenn Sie lernen, wie Sie einen Angriff abwehren können, haben Sie einen großen Vorsprung, wenn es darum geht, den anderen zu verhindern.

In dieser Folge lernen wir:

• Wie XML-Injektionen funktionieren
• Warum sie so gefährlich sind
• Wie Sie Verteidigungsmaßnahmen ergreifen können, um sie vollständig zu stoppen.

Wie lösen Angreifer XML-Injektionen aus?

XML-Injektionen sind immer dann erfolgreich, wenn ein nicht autorisierter Benutzer in der Lage ist, XML-Code zu schreiben und diesen in eine bestehende XML-Datenbank einzufügen. Damit dies funktioniert, sind nur zwei Dinge erforderlich: eine Anwendung, die sich auf eine XML-Datenbank stützt oder mit ihr verbunden ist, und ein ungesicherter Datenpfad, über den der Angreifer seinen Angriff starten kann.

XML-Injektionen sind fast immer erfolgreich, wenn die Benutzereingabe nicht bereinigt oder anderweitig eingeschränkt wird, bevor sie zur Verarbeitung an einen Server gesendet wird. Dies kann es Angreifern ermöglichen, ihren eigenen Code zu schreiben oder am Ende des normalen Query-Strings zu injizieren. Wenn dies erfolgreich ist, wird der Server dazu verleitet, den XML-Code auszuführen, wodurch er Datensätze hinzufügen oder löschen oder sogar eine ganze Datenbank offenlegen kann.

Hacker implementieren einen XML-Injection-Angriff, indem sie XML-Code zu einer normalen Abfrage hinzufügen. Dies kann alles sein, von einem Suchfeld bis hin zu einer Anmeldeseite. Es kann sogar Dinge wie Cookies oder Header enthalten.

In einem Registrierungsformular könnte ein Benutzer z. B. den folgenden Code nach dem Feld für den Benutzernamen oder das Kennwort hinzufügen:

<user></user>
<role>administrator</role>
<username>John_Smith</username><password>Jump783!Tango@12</password>

In diesem Beispiel würde ein neuer Benutzer namens "John_Smith" mit Administratorrechten erstellt. Wenigstens wendet der neue Benutzer gute Regeln für die Kennwortdichte an. Schade, dass er eigentlich ein Angreifer ist.

Hacker müssen nicht unbedingt immer einen solchen Homerun landen, um mit XML-Injections erfolgreich zu sein. Durch die Manipulation ihrer Abfragen und die Aufzeichnung der verschiedenen Fehlermeldungen, die der Server zurückgibt, können sie unter Umständen die Struktur der XML-Datenbank abbilden. Und diese Informationen können verwendet werden, um andere Arten von Angriffen zu verbessern.  

Warum sind XML-Injektionen so gefährlich?

Wie gefährlich ein XML-Injection-Angriff ist, hängt davon ab, welche Informationen in der anvisierten XML-Datenbank gespeichert sind bzw. wie diese Informationen verwendet werden. Im Falle einer XML-Datenbank, die zur Authentifizierung von Benutzern verwendet wird, kann eine XML-Injection einem Angreifer Zugriff auf das System verschaffen. Es könnte ihm sogar ermöglichen, Administrator im angegriffenen Netzwerk zu werden, was natürlich eine äußerst gefährliche Situation darstellt.

Bei XML-Injections, die sich gegen herkömmlichere Datenbanken richten, besteht die Gefahr darin, dass diese Informationen gestohlen werden, dass dem Speicher falsche Daten hinzugefügt werden oder dass möglicherweise gute Daten überschrieben werden. XML-Code ist nicht sehr schwer zu erlernen und einige der Befehle können extrem mächtig sein und ganze Informationsfelder überschreiben oder sogar den Inhalt eines Datenspeichers anzeigen.

Generell baut niemand eine Datenbank auf, wenn die dort gespeicherten Informationen keinen Wert haben. Hacker wissen das, weshalb sie es oft auf sie abgesehen haben. Wenn diese Daten Dinge wie persönliche Informationen über Mitarbeiter oder Kunden enthalten, kann eine Kompromittierung zu Reputationsverlust, finanziellen Konsequenzen, hohen Geldstrafen oder sogar Klagen führen.  

Stoppen von XML-Injektionsangriffen

XML-Injections sind aufgrund des geringen Schwierigkeitsgrads und der weiten Verbreitung von XML-Datenbanken relativ häufig. Aber diese Angriffe gibt es schon seit langem. Daher gibt es einige unumstößliche Fixes, die verhindern, dass sie jemals ausgeführt werden können.

Eine der besten Methoden zum Stoppen der Angriffe besteht darin, eine Anwendung so zu gestalten, dass sie nur vorkompilierte XML-Abfragen verwendet. Dadurch wird die Funktionalität der Abfragen auf eine autorisierte Teilmenge von Aktivitäten beschränkt. Alles, was mit zusätzlichen Argumenten oder Befehlen kommt, die nicht mit den vorkompilierten Abfragefunktionen übereinstimmen, wird einfach nicht ausgeführt. Wenn Sie nicht ganz so restriktiv sein wollen, können Sie auch Parametrisierung verwenden. Diese schränkt die Benutzereingabe auf bestimmte Abfrage- und Datentypen ein, z. B. nur auf Ganzzahlen. Alles, was außerhalb dieser Parameter liegt, wird als ungültig betrachtet und führt dazu, dass die Abfrage fehlschlägt.

Es ist auch eine gute Idee, vorkompilierte oder parametrisierte Abfragen mit angepassten Fehlermeldungen zu verbinden. Anstatt die standardmäßigen, beschreibenden Fehlermeldungen einer fehlgeschlagenen Abfrage zurückzusenden, sollten Anwendungen diese Antworten abfangen und durch eine allgemeinere Meldung ersetzen. Idealerweise wollen Sie dem Benutzer mitteilen, warum die Abfrage fehlgeschlagen ist, ihm aber keine Informationen über die Datenbank selbst geben. Wenn Sie diese benutzerdefinierten Meldungen auf einige wenige Auswahlmöglichkeiten beschränken, können Hacker keine nützlichen Informationen aus fehlgeschlagenen Abfragen zusammenstellen.

XML-Injektionen waren sehr erfolgreich, als sie zum ersten Mal entwickelt wurden. Aber wenn man bedenkt, wie lange das schon her ist, können wir heute ganz einfach Schutzmaßnahmen konstruieren, die nicht mehr durchbrochen werden können.

Mehr Informationen über XML Injections

Weitere Informationen finden Sie im OWASP-Artikel über XML-Injektionen. Sie können Ihr neu erworbenes Verteidigungswissen auch mit der kostenlosen Demo der Secure Code Warrior Plattform testen, die Cybersecurity-Teams zu den ultimativen Cyber Warriors ausbildet. Weitere Informationen über die Beseitigung dieser Sicherheitslücke und einer Reihe anderer Bedrohungen finden Sie im BlogSecure Code Warrior .