コーダーがセキュリティを征服する:共有して学ぶシリーズ-XML インジェクション
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 .
XMLインジェクション攻撃は、ハッカーがXMLデータベースをホストするシステムを侵害するために考案した厄介な小さなエクスプロイトです。これには、従来のデータベース、つまり医薬品から映画まであらゆる情報の詳細な保存場所について考えるときに思い浮かぶようなことが含まれます。
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
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 .
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 .
Klicken Sie auf den folgenden Link, um die PDF-Datei dieser Ressource herunterzuladen.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
Bericht anzeigenデモを予約
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
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 .
目次
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約[ダウンロード]Ressourcen für den Einstieg
Themen und Inhalte der Secure-Code-Schulung
Unsere branchenführenden Inhalte werden unter Berücksichtigung der Aufgaben unserer Kunden ständig weiterentwickelt, um mit der sich ständig verändernden Softwareentwicklungsumgebung Schritt zu halten. Sie decken alle Themen von KI bis hin zu XQuery-Injection ab und sind für verschiedene Aufgabenbereiche konzipiert, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätssicherungsfachleuten. Werfen Sie einen Blick auf die Inhalte unseres Content-Katalogs, sortiert nach Themen und Aufgabenbereichen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
「Cybermon 2025 Beat the Boss」 kann nun das ganze Jahr über bei SCW gespielt werden. Führen Sie anspruchsvolle AI/LLM-Sicherheitsherausforderungen ein, um die sichere AI-Entwicklung in großem Maßstab zu stärken.
Erläuterung des Cyber-Resilience-Gesetzes: Bedeutung für die Entwicklung sicherer Software
Erfahren Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams auf Secure-by-Design-Praktiken, Schwachstellenprävention und die Kompetenzentwicklung von Entwicklern vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 ist der erste Teil der zehnteiligen Reihe „Enablers of Success“ und zeigt, wie sichere Programmierung mit geschäftlichen Ergebnissen wie Risikominderung und Geschwindigkeit verknüpft werden kann, um Programme langfristig zu optimieren.
