Programmierer erobern die Sicherheit: Serie „Teilen und Lernen“ — XML Injections

XML-Injection-Angriffe sind fiese kleine Exploits, die von Hackern erfunden wurden, um ihnen zu helfen, Systeme zu kompromittieren, die XML-Datenbanken hosten. Dazu gehören Dinge, die einem in den Sinn kommen, wenn man an herkömmliche Datenbanken denkt — detaillierte Informationsspeicher über alles, von Medikamenten bis hin zu Filmen. Einige XML-Datenspeicher werden auch verwendet, um nach autorisierten Benutzern zu suchen. Wenn Sie also neuen XML-Code in sie einfügen, können neue Benutzer erstellt werden, die das Hostsystem ab diesem Zeitpunkt akzeptiert.

Damit ein Angreifer eine XML-Injektion implementieren kann, muss es eine Anwendung geben, die auf einer XML-Datenbank basiert oder zumindest auf sie zugreift. Immer wenn das passiert und 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 großen Schaden anrichten oder sogar den Zugriff auf die gesamte Datenbank ermöglichen.

Wenn Sie weiterlesen, stellen Sie möglicherweise fest, dass die XML-Injection eng mit den zuvor behandelten SQL-Injection-Angriffen zusammenhängt. Das liegt daran, dass sie sich, obwohl sie auf verschiedene Arten von Datenbanken abzielen, extrem ähnlich sind. Und zum Glück sind auch die Korrekturen ähnlich. Wenn Sie lernen, wie Sie eine Art von Angriff abwehren können, sind Sie dem Spiel einen Schritt voraus, wenn Sie daran arbeiten, die andere zu verhindern.

In dieser Episode werden wir lernen:

• So funktionieren XML-Injections
• Warum sie so gefährlich sind
• Wie Sie Abwehrmechanismen einrichten können, um sie vollständig zu stoppen.

Wie lösen Angreifer XML-Injections aus?

XML-Injektionen sind immer dann erfolgreich, wenn ein nicht autorisierter Benutzer in der Lage ist, XML-Code zu schreiben und ihn in eine bestehende XML-Datenbank einzufügen. Dazu sind nur zwei Dinge erforderlich, um zu funktionieren: eine Anwendung, die auf einer XML-Datenbank basiert oder eine Verbindung zu einer XML-Datenbank herstellt, und ein ungesicherter Datenpfad, über den der Angreifer seinen Angriff starten kann.

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

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

Beispielsweise kann ein Benutzer in einem Registrierungsformular den folgenden Code nach dem Feld für den Benutzernamen oder das Passwort hinzufügen:

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

In diesem Beispiel würde ein neuer Benutzer mit dem Namen John_Smith mit Administratorzugriff erstellt werden. Zumindest wendet der neue Benutzer gute Regeln für die Passwortdichte an. Schade, dass sie tatsächlich ein Angreifer sind.

Hacker müssen nicht unbedingt immer einen solchen Homerun hinlegen, um mit XML-Injections erfolgreich zu sein. Indem sie ihre Abfragen manipulieren und die verschiedenen Fehlermeldungen aufzeichnen, die der Server zurückgibt, sind sie möglicherweise in der Lage, die Struktur der XML-Datenbank abzubilden. Und diese Informationen können verwendet werden, um andere Arten von Angriffen zu verstärken.

Warum sind XML-Injektionen so gefährlich?

Der Grad der Gefahr, die von einem XML-Injection-Angriff ausgeht, hängt davon ab, welche Informationen in der Ziel-XML-Datenbank gespeichert sind oder wie diese Informationen verwendet werden. Wenn beispielsweise eine XML-Datenbank zur Authentifizierung von Benutzern verwendet wird, kann eine XML-Injektion einem Angreifer Zugriff auf das System gewähren. Es könnte ihnen sogar ermöglichen, Administrator im Zielnetzwerk zu werden, was natürlich eine äußerst gefährliche Situation ist.

Bei XML-Injektionen gegen traditionellere Datenbanken besteht die Gefahr, dass diese Informationen gestohlen werden, dass falsche Daten zum Speicher hinzugefügt werden oder möglicherweise fehlerhafte 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.

Im Allgemeinen erstellt niemand eine Datenbank, es sei denn, die dort gespeicherten Informationen haben einen Wert. Hacker wissen das, weshalb sie sie oft ins Visier nehmen. Wenn diese Daten Dinge wie persönliche Daten von Mitarbeitern oder Kunden enthalten, kann eine Kompromittierung zu Reputationsverlust, finanziellen Folgen, hohen Bußgeldern oder sogar zu Gerichtsverfahren führen.

Stoppen von XML-Injection-Angriffen

XML-Injections sind aufgrund des geringen Schwierigkeitsgrades bei der Durchführung einer Injektion und der Verbreitung von XML-Datenbanken ziemlich häufig. Aber diese Angriffe gibt es schon lange. Daher gibt es mehrere unumstößliche Korrekturen, die verhindern, dass sie jemals ausgeführt werden.

Eine der besten Methoden, um die Angriffe zu stoppen, besteht darin, eine Anwendung so zu entwerfen, 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 zusätzliche Argumente oder Befehle enthält, die nicht mit den vorkompilierten Abfragefunktionen übereinstimmen, wird einfach nicht ausgeführt. Wenn Sie nicht ganz so restriktiv sein möchten, können Sie auch die Parametrisierung verwenden. Dadurch werden Benutzereingaben auf bestimmte Arten von Abfragen und Daten beschränkt, z. B. auf die Verwendung von Ganzzahlen. Alles, was außerhalb dieser Parameter liegt, wird als ungültig betrachtet und führt zum Fehlschlagen der Abfrage.

Es ist auch eine gute Idee, vorkompilierte oder parametrisierte Abfragen mit benutzerdefinierten Fehlermeldungen zu kombinieren. Anstatt die standardmäßigen, beschreibenden Fehlermeldungen nach einer fehlgeschlagenen Abfrage zurückzugeben, sollten Anwendungen diese Antworten abfangen und durch eine allgemeinere Meldung ersetzen. Im Idealfall sollten Sie einem Benutzer mitteilen, warum die Abfrage fehlgeschlagen ist, ihm aber keine Informationen über die Datenbank selbst geben. Wenn Sie diese benutzerdefinierten Nachrichten auf einige wenige Auswahlmöglichkeiten beschränken, können Hacker aus fehlgeschlagenen Abfragen keine brauchbaren Erkenntnisse gewinnen.

XML-Injektionen waren sehr erfolgreich, als sie zum ersten Mal entwickelt wurden. Aber wenn man bedenkt, wie lange das her ist, können wir heute problemlos Abwehrmechanismen aufbauen, die nicht mehr durchbrochen werden können.

Weitere Informationen zu XML Injections

Für weitere Informationen können Sie sich die OWASP ansehen schreiben Sie auf XML-Injektionen. Sie können Ihr neu gewonnenes Defensivwissen auch auf die Probe stellen mit dem kostenlose Demo der Secure Code Warrior-Plattform, die Cybersicherheitsteams zu ultimativen Cyberkriegern ausbildet. Um mehr über die Beseitigung dieser Sicherheitslücke und eine Galerie mit anderen Bedrohungen zu erfahren, besuchen Sie die Blog von Secure Code Warrior.