Coders Conquer Security: Share & Learn Series - XXE Injection
Der Angriff "XML External Entity Injection", manchmal einfach als XXE-Injektion abgekürzt, ist relativ neu im Vergleich zu einigen der klassischen Schwachstellen, die auch Jahre nach ihrer Entstehung noch die Runde machen. Aber sie ist in den Hacker-Communities derzeit extrem beliebt und wird mit zunehmenden Erfolgen immer beliebter.
Tatsächlich listet OWASP XXE Injection jetzt als eine der zehn größten Schwachstellen auf, auf die Websites achten und sich aktiv dagegen schützen müssen. Aber keine Sorge, XXE Injection ist nicht mächtiger als andere Exploits, die bei Cyberangriffen eingesetzt werden. Sie ist nur ein bisschen neuer und weniger bekannt. Sie kann verhindert und sogar komplett gestoppt werden.
In dieser Folge lernen wir:
- Wie Angreifer XXE-Injektionen verwenden
- Warum die XXE-Injektion gefährlich ist
- Techniken, die diese Sicherheitslücke verhindern können.
Wie lösen Angreifer eine XXE-Injektion aus?
Die XXE-Injection-Schwachstelle kann auftreten, wenn ein böswilliger Benutzer die Möglichkeit erhält, XML-Code zu übermitteln. Er nutzt diese Fähigkeit, um einen Verweis auf eine externe Entität zu erstellen. Der externe Verweis und der Code sind so konzipiert, dass sie an einem XML-Parser mit Standardeinstellungen oder einem mit schwach konfigurierten Einstellungen vorbeigehen.
Der Angreifer nutzt die Tatsache aus, dass der XML-Standard das Konzept einer Entität als eine Speichereinheit irgendeiner Art definiert, wobei dieser Speicher extern oder intern sein kann. Richtig eingesetzt, kann er XML-Prozessoren den Zugriff auf entfernte Ressourcen ermöglichen. Meistens nutzen Angreifer diese Fähigkeit, um z.B. die interne Struktur einer Website zu sondieren, eine Denial-of-Service-Attacke zu starten, indem sie große Systemprozesse auslösen, die versuchen, auf Remote-Ressourcen zuzugreifen, oder sogar Daten von einem lokalen Host auf einen Remote-Host zu dumpen, den sie kontrollieren ", was es zu einer guten Technik macht, um wichtige Daten wie Passwörter oder persönliche Informationen, die in der XML-Datenbank enthalten sind, zu exfiltrieren.
Der eigentliche Code, der in den Angriff involviert ist, ist oft recht simpel und nutzt lediglich die Funktionalität der Entität aus. Dies könnte einem Hacker beispielsweise den Zugriff auf die Master-Kennwortdatei ermöglichen:
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
Warum ist die XXE-Injektion gefährlich?
Es gibt ein paar Gründe, warum XXE-Injection-Angriffe so gefährlich und auch weit verbreitet sind. Zum einen ist es eine noch wenig bekannte Sicherheitslücke. Und die Gewinne, die ein Angreifer durch das Ausnutzen dieser Schwachstelle erzielen kann, sind beträchtlich. Zum einen kann sie hartnäckigen Angreifern erlauben, langsam alle Pfade in einem internen Netzwerk abzubilden oder sogar Ports zu scannen. Obwohl dies eine gewisse Zeit in Anspruch nehmen kann, besteht fast keine Chance, dass die Aktivitäten eines Hackers von aktiven Verteidigungsmaßnahmen im Zielnetzwerk aufgedeckt werden, da er einfach XML-Code an einen Server sendet, der von dem vertrauenswürdigen XML-Parser freigegeben wird.
Sobald eine Zuordnung erfolgt ist, können Angreifer dieselben XXE-Injection-Techniken verwenden, um beliebige Dateien zu erbeuten, entweder direkt, um Informationen zu stehlen, oder indem sie gültige Benutzeranmeldeinformationen kompromittieren und sie für sekundäre Angriffe verwenden. Schließlich können Angreifer, die einfach nur Lärm machen und böswillig sein wollen, Dinge wie das Auslösen von Denial-of-Service-Angriffen tun, indem sie der Anwendung befehlen, zu versuchen, auf entfernte Ressourcen zuzugreifen, um das System lahmzulegen.
Beseitigung der XXE-Injection-Schwachstelle
Aufgrund der rapiden Zunahme von XXE-Injection-Attacken gehen viele XML-Parser dazu über, externe Entitäten, manchmal auch DTDs genannt, standardmäßig komplett zu deaktivieren. In diesen Fällen besteht der Schlüssel darin, diese Funktionalität einfach nicht zu aktivieren.
Aber auch bei Parsern, die DTDs zulassen, kann diese Funktionalität deaktiviert werden. Im Allgemeinen wird eine Anweisung wie die folgende benötigt, um sie vollständig zu blockieren, aber sehen Sie in der Dokumentation Ihres lokalen Frameworks nach, um den genauen benötigten Code zu erhalten.
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
Gemäß den Sicherheitsprinzipien sollten alle Benutzereingaben mit anwendungsweiten Filtern bereinigt und validiert werden. Vergessen Sie nicht, GET- und POST-Parameter, HTTP-Header und Cookies einzubeziehen. Sie können auch eine Whitelist mit bestimmten DTDs und Befehlen erstellen, die der Parser verarbeiten soll, und alles andere verbieten.
Obwohl Whitelisting und Filterung funktionieren, wird aufgrund der steigenden Anzahl von XXE-Injection-Angriffen dennoch empfohlen, die DTD-Unterstützung komplett zu deaktivieren, wenn die Funktionalität nicht benötigt wird.
Mehr Informationen über XXE Injections
Als weitere Lektüre können Sie einen Blick darauf werfen, was OWASP über XXE-Injection-Angriffe sagt. 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-Kriegern ausbildet. Um mehr darüber zu erfahren, wie Sie diese Schwachstelle und andere Bedrohungen abwehren können, besuchen Sie den BlogSecure Code Warrior .


Der XML External Entity Injection-Angriff, der manchmal einfach als XXE-Injection abgekürzt wird, ist relativ neu, erfreut sich aber in den Hacker-Communities derzeit großer Beliebtheit und wird mit zunehmendem Erfolg immer beliebter.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen

Der Angriff "XML External Entity Injection", manchmal einfach als XXE-Injektion abgekürzt, ist relativ neu im Vergleich zu einigen der klassischen Schwachstellen, die auch Jahre nach ihrer Entstehung noch die Runde machen. Aber sie ist in den Hacker-Communities derzeit extrem beliebt und wird mit zunehmenden Erfolgen immer beliebter.
Tatsächlich listet OWASP XXE Injection jetzt als eine der zehn größten Schwachstellen auf, auf die Websites achten und sich aktiv dagegen schützen müssen. Aber keine Sorge, XXE Injection ist nicht mächtiger als andere Exploits, die bei Cyberangriffen eingesetzt werden. Sie ist nur ein bisschen neuer und weniger bekannt. Sie kann verhindert und sogar komplett gestoppt werden.
In dieser Folge lernen wir:
- Wie Angreifer XXE-Injektionen verwenden
- Warum die XXE-Injektion gefährlich ist
- Techniken, die diese Sicherheitslücke verhindern können.
Wie lösen Angreifer eine XXE-Injektion aus?
Die XXE-Injection-Schwachstelle kann auftreten, wenn ein böswilliger Benutzer die Möglichkeit erhält, XML-Code zu übermitteln. Er nutzt diese Fähigkeit, um einen Verweis auf eine externe Entität zu erstellen. Der externe Verweis und der Code sind so konzipiert, dass sie an einem XML-Parser mit Standardeinstellungen oder einem mit schwach konfigurierten Einstellungen vorbeigehen.
Der Angreifer nutzt die Tatsache aus, dass der XML-Standard das Konzept einer Entität als eine Speichereinheit irgendeiner Art definiert, wobei dieser Speicher extern oder intern sein kann. Richtig eingesetzt, kann er XML-Prozessoren den Zugriff auf entfernte Ressourcen ermöglichen. Meistens nutzen Angreifer diese Fähigkeit, um z.B. die interne Struktur einer Website zu sondieren, eine Denial-of-Service-Attacke zu starten, indem sie große Systemprozesse auslösen, die versuchen, auf Remote-Ressourcen zuzugreifen, oder sogar Daten von einem lokalen Host auf einen Remote-Host zu dumpen, den sie kontrollieren ", was es zu einer guten Technik macht, um wichtige Daten wie Passwörter oder persönliche Informationen, die in der XML-Datenbank enthalten sind, zu exfiltrieren.
Der eigentliche Code, der in den Angriff involviert ist, ist oft recht simpel und nutzt lediglich die Funktionalität der Entität aus. Dies könnte einem Hacker beispielsweise den Zugriff auf die Master-Kennwortdatei ermöglichen:
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
Warum ist die XXE-Injektion gefährlich?
Es gibt ein paar Gründe, warum XXE-Injection-Angriffe so gefährlich und auch weit verbreitet sind. Zum einen ist es eine noch wenig bekannte Sicherheitslücke. Und die Gewinne, die ein Angreifer durch das Ausnutzen dieser Schwachstelle erzielen kann, sind beträchtlich. Zum einen kann sie hartnäckigen Angreifern erlauben, langsam alle Pfade in einem internen Netzwerk abzubilden oder sogar Ports zu scannen. Obwohl dies eine gewisse Zeit in Anspruch nehmen kann, besteht fast keine Chance, dass die Aktivitäten eines Hackers von aktiven Verteidigungsmaßnahmen im Zielnetzwerk aufgedeckt werden, da er einfach XML-Code an einen Server sendet, der von dem vertrauenswürdigen XML-Parser freigegeben wird.
Sobald eine Zuordnung erfolgt ist, können Angreifer dieselben XXE-Injection-Techniken verwenden, um beliebige Dateien zu erbeuten, entweder direkt, um Informationen zu stehlen, oder indem sie gültige Benutzeranmeldeinformationen kompromittieren und sie für sekundäre Angriffe verwenden. Schließlich können Angreifer, die einfach nur Lärm machen und böswillig sein wollen, Dinge wie das Auslösen von Denial-of-Service-Angriffen tun, indem sie der Anwendung befehlen, zu versuchen, auf entfernte Ressourcen zuzugreifen, um das System lahmzulegen.
Beseitigung der XXE-Injection-Schwachstelle
Aufgrund der rapiden Zunahme von XXE-Injection-Attacken gehen viele XML-Parser dazu über, externe Entitäten, manchmal auch DTDs genannt, standardmäßig komplett zu deaktivieren. In diesen Fällen besteht der Schlüssel darin, diese Funktionalität einfach nicht zu aktivieren.
Aber auch bei Parsern, die DTDs zulassen, kann diese Funktionalität deaktiviert werden. Im Allgemeinen wird eine Anweisung wie die folgende benötigt, um sie vollständig zu blockieren, aber sehen Sie in der Dokumentation Ihres lokalen Frameworks nach, um den genauen benötigten Code zu erhalten.
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
Gemäß den Sicherheitsprinzipien sollten alle Benutzereingaben mit anwendungsweiten Filtern bereinigt und validiert werden. Vergessen Sie nicht, GET- und POST-Parameter, HTTP-Header und Cookies einzubeziehen. Sie können auch eine Whitelist mit bestimmten DTDs und Befehlen erstellen, die der Parser verarbeiten soll, und alles andere verbieten.
Obwohl Whitelisting und Filterung funktionieren, wird aufgrund der steigenden Anzahl von XXE-Injection-Angriffen dennoch empfohlen, die DTD-Unterstützung komplett zu deaktivieren, wenn die Funktionalität nicht benötigt wird.
Mehr Informationen über XXE Injections
Als weitere Lektüre können Sie einen Blick darauf werfen, was OWASP über XXE-Injection-Angriffe sagt. 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-Kriegern ausbildet. Um mehr darüber zu erfahren, wie Sie diese Schwachstelle und andere Bedrohungen abwehren können, besuchen Sie den BlogSecure Code Warrior .

Der Angriff "XML External Entity Injection", manchmal einfach als XXE-Injektion abgekürzt, ist relativ neu im Vergleich zu einigen der klassischen Schwachstellen, die auch Jahre nach ihrer Entstehung noch die Runde machen. Aber sie ist in den Hacker-Communities derzeit extrem beliebt und wird mit zunehmenden Erfolgen immer beliebter.
Tatsächlich listet OWASP XXE Injection jetzt als eine der zehn größten Schwachstellen auf, auf die Websites achten und sich aktiv dagegen schützen müssen. Aber keine Sorge, XXE Injection ist nicht mächtiger als andere Exploits, die bei Cyberangriffen eingesetzt werden. Sie ist nur ein bisschen neuer und weniger bekannt. Sie kann verhindert und sogar komplett gestoppt werden.
In dieser Folge lernen wir:
- Wie Angreifer XXE-Injektionen verwenden
- Warum die XXE-Injektion gefährlich ist
- Techniken, die diese Sicherheitslücke verhindern können.
Wie lösen Angreifer eine XXE-Injektion aus?
Die XXE-Injection-Schwachstelle kann auftreten, wenn ein böswilliger Benutzer die Möglichkeit erhält, XML-Code zu übermitteln. Er nutzt diese Fähigkeit, um einen Verweis auf eine externe Entität zu erstellen. Der externe Verweis und der Code sind so konzipiert, dass sie an einem XML-Parser mit Standardeinstellungen oder einem mit schwach konfigurierten Einstellungen vorbeigehen.
Der Angreifer nutzt die Tatsache aus, dass der XML-Standard das Konzept einer Entität als eine Speichereinheit irgendeiner Art definiert, wobei dieser Speicher extern oder intern sein kann. Richtig eingesetzt, kann er XML-Prozessoren den Zugriff auf entfernte Ressourcen ermöglichen. Meistens nutzen Angreifer diese Fähigkeit, um z.B. die interne Struktur einer Website zu sondieren, eine Denial-of-Service-Attacke zu starten, indem sie große Systemprozesse auslösen, die versuchen, auf Remote-Ressourcen zuzugreifen, oder sogar Daten von einem lokalen Host auf einen Remote-Host zu dumpen, den sie kontrollieren ", was es zu einer guten Technik macht, um wichtige Daten wie Passwörter oder persönliche Informationen, die in der XML-Datenbank enthalten sind, zu exfiltrieren.
Der eigentliche Code, der in den Angriff involviert ist, ist oft recht simpel und nutzt lediglich die Funktionalität der Entität aus. Dies könnte einem Hacker beispielsweise den Zugriff auf die Master-Kennwortdatei ermöglichen:
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
Warum ist die XXE-Injektion gefährlich?
Es gibt ein paar Gründe, warum XXE-Injection-Angriffe so gefährlich und auch weit verbreitet sind. Zum einen ist es eine noch wenig bekannte Sicherheitslücke. Und die Gewinne, die ein Angreifer durch das Ausnutzen dieser Schwachstelle erzielen kann, sind beträchtlich. Zum einen kann sie hartnäckigen Angreifern erlauben, langsam alle Pfade in einem internen Netzwerk abzubilden oder sogar Ports zu scannen. Obwohl dies eine gewisse Zeit in Anspruch nehmen kann, besteht fast keine Chance, dass die Aktivitäten eines Hackers von aktiven Verteidigungsmaßnahmen im Zielnetzwerk aufgedeckt werden, da er einfach XML-Code an einen Server sendet, der von dem vertrauenswürdigen XML-Parser freigegeben wird.
Sobald eine Zuordnung erfolgt ist, können Angreifer dieselben XXE-Injection-Techniken verwenden, um beliebige Dateien zu erbeuten, entweder direkt, um Informationen zu stehlen, oder indem sie gültige Benutzeranmeldeinformationen kompromittieren und sie für sekundäre Angriffe verwenden. Schließlich können Angreifer, die einfach nur Lärm machen und böswillig sein wollen, Dinge wie das Auslösen von Denial-of-Service-Angriffen tun, indem sie der Anwendung befehlen, zu versuchen, auf entfernte Ressourcen zuzugreifen, um das System lahmzulegen.
Beseitigung der XXE-Injection-Schwachstelle
Aufgrund der rapiden Zunahme von XXE-Injection-Attacken gehen viele XML-Parser dazu über, externe Entitäten, manchmal auch DTDs genannt, standardmäßig komplett zu deaktivieren. In diesen Fällen besteht der Schlüssel darin, diese Funktionalität einfach nicht zu aktivieren.
Aber auch bei Parsern, die DTDs zulassen, kann diese Funktionalität deaktiviert werden. Im Allgemeinen wird eine Anweisung wie die folgende benötigt, um sie vollständig zu blockieren, aber sehen Sie in der Dokumentation Ihres lokalen Frameworks nach, um den genauen benötigten Code zu erhalten.
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
Gemäß den Sicherheitsprinzipien sollten alle Benutzereingaben mit anwendungsweiten Filtern bereinigt und validiert werden. Vergessen Sie nicht, GET- und POST-Parameter, HTTP-Header und Cookies einzubeziehen. Sie können auch eine Whitelist mit bestimmten DTDs und Befehlen erstellen, die der Parser verarbeiten soll, und alles andere verbieten.
Obwohl Whitelisting und Filterung funktionieren, wird aufgrund der steigenden Anzahl von XXE-Injection-Angriffen dennoch empfohlen, die DTD-Unterstützung komplett zu deaktivieren, wenn die Funktionalität nicht benötigt wird.
Mehr Informationen über XXE Injections
Als weitere Lektüre können Sie einen Blick darauf werfen, was OWASP über XXE-Injection-Angriffe sagt. 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-Kriegern ausbildet. Um mehr darüber zu erfahren, wie Sie diese Schwachstelle und andere Bedrohungen abwehren können, besuchen Sie den BlogSecure Code Warrior .

Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchenDer Angriff "XML External Entity Injection", manchmal einfach als XXE-Injektion abgekürzt, ist relativ neu im Vergleich zu einigen der klassischen Schwachstellen, die auch Jahre nach ihrer Entstehung noch die Runde machen. Aber sie ist in den Hacker-Communities derzeit extrem beliebt und wird mit zunehmenden Erfolgen immer beliebter.
Tatsächlich listet OWASP XXE Injection jetzt als eine der zehn größten Schwachstellen auf, auf die Websites achten und sich aktiv dagegen schützen müssen. Aber keine Sorge, XXE Injection ist nicht mächtiger als andere Exploits, die bei Cyberangriffen eingesetzt werden. Sie ist nur ein bisschen neuer und weniger bekannt. Sie kann verhindert und sogar komplett gestoppt werden.
In dieser Folge lernen wir:
- Wie Angreifer XXE-Injektionen verwenden
- Warum die XXE-Injektion gefährlich ist
- Techniken, die diese Sicherheitslücke verhindern können.
Wie lösen Angreifer eine XXE-Injektion aus?
Die XXE-Injection-Schwachstelle kann auftreten, wenn ein böswilliger Benutzer die Möglichkeit erhält, XML-Code zu übermitteln. Er nutzt diese Fähigkeit, um einen Verweis auf eine externe Entität zu erstellen. Der externe Verweis und der Code sind so konzipiert, dass sie an einem XML-Parser mit Standardeinstellungen oder einem mit schwach konfigurierten Einstellungen vorbeigehen.
Der Angreifer nutzt die Tatsache aus, dass der XML-Standard das Konzept einer Entität als eine Speichereinheit irgendeiner Art definiert, wobei dieser Speicher extern oder intern sein kann. Richtig eingesetzt, kann er XML-Prozessoren den Zugriff auf entfernte Ressourcen ermöglichen. Meistens nutzen Angreifer diese Fähigkeit, um z.B. die interne Struktur einer Website zu sondieren, eine Denial-of-Service-Attacke zu starten, indem sie große Systemprozesse auslösen, die versuchen, auf Remote-Ressourcen zuzugreifen, oder sogar Daten von einem lokalen Host auf einen Remote-Host zu dumpen, den sie kontrollieren ", was es zu einer guten Technik macht, um wichtige Daten wie Passwörter oder persönliche Informationen, die in der XML-Datenbank enthalten sind, zu exfiltrieren.
Der eigentliche Code, der in den Angriff involviert ist, ist oft recht simpel und nutzt lediglich die Funktionalität der Entität aus. Dies könnte einem Hacker beispielsweise den Zugriff auf die Master-Kennwortdatei ermöglichen:
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
Warum ist die XXE-Injektion gefährlich?
Es gibt ein paar Gründe, warum XXE-Injection-Angriffe so gefährlich und auch weit verbreitet sind. Zum einen ist es eine noch wenig bekannte Sicherheitslücke. Und die Gewinne, die ein Angreifer durch das Ausnutzen dieser Schwachstelle erzielen kann, sind beträchtlich. Zum einen kann sie hartnäckigen Angreifern erlauben, langsam alle Pfade in einem internen Netzwerk abzubilden oder sogar Ports zu scannen. Obwohl dies eine gewisse Zeit in Anspruch nehmen kann, besteht fast keine Chance, dass die Aktivitäten eines Hackers von aktiven Verteidigungsmaßnahmen im Zielnetzwerk aufgedeckt werden, da er einfach XML-Code an einen Server sendet, der von dem vertrauenswürdigen XML-Parser freigegeben wird.
Sobald eine Zuordnung erfolgt ist, können Angreifer dieselben XXE-Injection-Techniken verwenden, um beliebige Dateien zu erbeuten, entweder direkt, um Informationen zu stehlen, oder indem sie gültige Benutzeranmeldeinformationen kompromittieren und sie für sekundäre Angriffe verwenden. Schließlich können Angreifer, die einfach nur Lärm machen und böswillig sein wollen, Dinge wie das Auslösen von Denial-of-Service-Angriffen tun, indem sie der Anwendung befehlen, zu versuchen, auf entfernte Ressourcen zuzugreifen, um das System lahmzulegen.
Beseitigung der XXE-Injection-Schwachstelle
Aufgrund der rapiden Zunahme von XXE-Injection-Attacken gehen viele XML-Parser dazu über, externe Entitäten, manchmal auch DTDs genannt, standardmäßig komplett zu deaktivieren. In diesen Fällen besteht der Schlüssel darin, diese Funktionalität einfach nicht zu aktivieren.
Aber auch bei Parsern, die DTDs zulassen, kann diese Funktionalität deaktiviert werden. Im Allgemeinen wird eine Anweisung wie die folgende benötigt, um sie vollständig zu blockieren, aber sehen Sie in der Dokumentation Ihres lokalen Frameworks nach, um den genauen benötigten Code zu erhalten.
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
Gemäß den Sicherheitsprinzipien sollten alle Benutzereingaben mit anwendungsweiten Filtern bereinigt und validiert werden. Vergessen Sie nicht, GET- und POST-Parameter, HTTP-Header und Cookies einzubeziehen. Sie können auch eine Whitelist mit bestimmten DTDs und Befehlen erstellen, die der Parser verarbeiten soll, und alles andere verbieten.
Obwohl Whitelisting und Filterung funktionieren, wird aufgrund der steigenden Anzahl von XXE-Injection-Angriffen dennoch empfohlen, die DTD-Unterstützung komplett zu deaktivieren, wenn die Funktionalität nicht benötigt wird.
Mehr Informationen über XXE Injections
Als weitere Lektüre können Sie einen Blick darauf werfen, was OWASP über XXE-Injection-Angriffe sagt. 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-Kriegern ausbildet. Um mehr darüber zu erfahren, wie Sie diese Schwachstelle und andere Bedrohungen abwehren können, besuchen Sie den BlogSecure Code Warrior .
Inhaltsübersicht

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Aussagekräftige Daten über den Erfolg von Secure-by-Design-Initiativen zu finden, ist bekanntermaßen schwierig. CISOs stehen oft vor der Herausforderung, den Return on Investment (ROI) und den Geschäftswert von Sicherheitsprogrammen sowohl auf Mitarbeiter- als auch auf Unternehmensebene nachzuweisen. Ganz zu schweigen davon, dass es für Unternehmen besonders schwierig ist, Erkenntnisse darüber zu gewinnen, wie ihre Organisation im Vergleich zu aktuellen Branchenstandards abschneidet. Die Nationale Cybersicherheitsstrategie des Präsidenten forderte die Beteiligten auf, "Sicherheit und Widerstandsfähigkeit durch Design" zu erreichen. Der Schlüssel zum Erfolg von Secure-by-Design-Initiativen liegt nicht nur darin, Entwicklern die nötigen Fähigkeiten zu vermitteln, um sicheren Code zu gewährleisten, sondern auch darin, den Aufsichtsbehörden zu versichern, dass diese Fähigkeiten vorhanden sind. In dieser Präsentation stellen wir eine Vielzahl von qualitativen und quantitativen Daten vor, die aus verschiedenen Primärquellen stammen, darunter interne Daten von über 250.000 Entwicklern, datengestützte Kundeneinblicke und öffentliche Studien. Auf der Grundlage dieser gesammelten Daten wollen wir eine Vision des aktuellen Stands von Secure-by-Design-Initiativen in verschiedenen Branchen vermitteln. Der Bericht zeigt auf, warum dieser Bereich derzeit nicht ausreichend genutzt wird, welche erheblichen Auswirkungen ein erfolgreiches Schulungsprogramm auf die Minderung von Cybersecurity-Risiken haben kann und welches Potenzial zur Beseitigung von Schwachstellen in einer Codebasis besteht.
Professionelle Dienstleistungen - Beschleunigen Sie mit Fachwissen
Das PSS-Team (Program Strategy Services) von Secure Code Warriorunterstützt Sie beim Aufbau, der Verbesserung und der Optimierung Ihres Programms für sichere Codierung. Ganz gleich, ob Sie neu anfangen oder Ihren Ansatz verfeinern möchten, unsere Experten bieten Ihnen maßgeschneiderte Beratung.
Themen und Inhalte der Schulung zu sicherem Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sie an die sich ständig verändernde Softwareentwicklungslandschaft anzupassen und Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis XQuery Injection und werden für eine Vielzahl von Rollen angeboten, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Überblick über die Inhalte, die unser Katalog nach Thema und Rolle bietet.
Quests: Branchenführendes Lernen, damit die Entwickler immer einen Schritt voraus sind und Risiken minimiert werden.
Quests ist eine learning platform , die Entwicklern hilft, Software-Sicherheitsrisiken zu verringern, indem sie ihre Fähigkeiten zur sicheren Programmierung verbessern. Mit kuratierten Lernpfaden, praktischen Herausforderungen und interaktiven Aktivitäten befähigt sie Entwickler, Schwachstellen zu erkennen und zu vermeiden.
Ressourcen für den Einstieg
Wird Vibe Coding Ihre Codebasis in eine Verbindungsparty verwandeln?
Vibe Coding ist wie eine College-Verbindungsparty, und AI ist das Herzstück aller Festivitäten, das Fass. Es macht eine Menge Spaß, sich auszutoben, kreativ zu werden und zu sehen, wohin die eigene Fantasie einen führen kann, aber nach ein paar Bierfässern ist das Trinken (oder die Verwendung von KI) in Maßen zweifellos die sicherere langfristige Lösung.
Das Jahrzehnt der Defenders: Secure Code Warrior Zehnte Runde
Secure Code WarriorDas Gründungsteam von SCW ist zusammengeblieben und hat das Schiff ein ganzes Jahrzehnt lang durch alle Lektionen, Triumphe und Rückschläge gesteuert. Wir vergrößern uns und sind bereit für unser nächstes Kapitel, SCW 2.0, als führendes Unternehmen im Risikomanagement für Entwickler.