Skip to content

XML-Sicherheit, Teil 5: XSL Injection, zum zweiten

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

"XML-Sicherheit, Teil 5: XSL Injection, zum zweiten" vollständig lesen

XML-Sicherheit, Teil 4: XSL Injection, zum ersten

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.

Ab dieser Folge geht es um weitere Angriffe auf bzw. über XML. Zuerst um

Angriffe auf Extensible Stylesheet Language Transformations (XSLT)

"XML-Sicherheit, Teil 4: XSL Injection, zum ersten" vollständig lesen

XML-Sicherheit, Teil 3: XXE-Angriffe, zum dritten!

Die XXE-Angriffe stehen auf Platz 4 der aktuellen OWASP Top 10. Worum es dabei 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 damit ist noch lange nicht Schluss:

Weitere XXE-Schwachstellen

2014: XXE in SAML-Interfaces

"XML-Sicherheit, Teil 3: XXE-Angriffe, zum dritten!" vollständig lesen

XML-Sicherheit, Teil 1: XXE-Angriffe, zum ersten!

XML wird meist für den Austausch von Daten verwendet. Werden die XML-Daten vor der Verarbeitung nicht geprüft, kann ein Angreifer darüber eigenen XML-Code einschleusen. Meist kommt es dann zu XML External Entity (XXE) Angriffen, die in den aktuellen OWASP Top 10 einen eigenen Eintrag haben: Sie stehen auf Platz 4. Aber auch andere Angriffe sind über XML möglich.

OWASP Top 10, 2017, Platz 4: XML External Entities (XXE)

"XML-Sicherheit, Teil 1: XXE-Angriffe, zum ersten!" vollständig lesen

DevOps-Sicherheit, Teil 2: Fallstricke und Vorteile

Wie es mit der sicheren Entwicklung in Theorie und Praxis aussieht, sowohl Allgemein als auch im Fall von DevOps, habe ich bereits im ersten Teil beschrieben. DevOps führt zu zusätzlicher Kommunikation zwischen Entwicklung und Betrieb, außerdem werden möglichst viele Aufgaben automatisiert, um menschliche Fehler zu reduzieren und die Qualität und Konsistenz der Ergebnisse zu verbessern.

Vorsicht, Gefahr!

"DevOps-Sicherheit, Teil 2: Fallstricke und Vorteile" vollständig lesen

DevOps-Sicherheit, Teil 1: Sichere Entwicklung in Theorie und Praxis

In DevOps steht bekanntlich das "Dev" für "Development" und das "Ops" für "Operations" - also Entwicklung und Betrieb. Sicherheit kommt darin nicht vor, obwohl sie doch so wichtig ist. Und obwohl sie sich gerade mit DevOps verbessern lässt, wenn man das denn möchte. Und wer möchte das schon nicht?

Theoretisch sicher

"DevOps-Sicherheit, Teil 1: Sichere Entwicklung in Theorie und Praxis" vollständig lesen

Identitätsdiebstahl Teil 5 - Was muss man tun, wenn man zum Opfer wird?

Dass der "Identitätsdiebstahl" ja eigentlich gar keine Diebstahl ist habe ich im ersten Teil erklärt. Im zweiten und dritten Teil ging es um verschiedene Möglichkeiten, Identität zu "stehlen". Und im vierten Teil habe ich dann einige echte Fälle von Identitätsdiebstahl vorgestellt. Jetzt geht es um die Frage, was die Opfer eines Identitätsdiebstahls tun müssen.

Opfer eines Identitätsmissbrauchs - was nun?

"Identitätsdiebstahl Teil 5 - Was muss man tun, wenn man zum Opfer wird?" vollständig lesen

Identitätsdiebstahl Teil 4 - Beispiele aus der Praxis

Dass der "Identitätsdiebstahl" ja eigentlich gar keine Diebstahl ist habe ich im ersten Teil erklärt. Im zweiten Teil ging es um drei Möglichkeiten, Identität zu "stehlen": Phishing, Ködern und kompromittierte (Web-)Server. Und im dritten Teil kamen mit Spyware und einfachem Anmelden zwei weitere Möglichkeiten dazu. Außerdem gab es erste Beispiele dafür, wie ein Identitätsmissbrauch erkannt werden kann. In dieser Folge gibt es einige Beispiele aus der Praxis.

Identitätsmissbrauch - Beispiele aus der Praxis

"Identitätsdiebstahl Teil 4 - Beispiele aus der Praxis" vollständig lesen

WebAssembly - Ist das sicher oder kann das weg?

Schon wieder eine neue Technologie für aktive Inhalte – muss das denn wirklich sein? Als hätten wir mit Flash und Java nicht schon genug Ärger gehabt.

Beides wurde wahrscheinlich öfter für Angriffe als für wirklich nützliche Anwendungen verwendet. Jedenfalls wenn man mal von Spielen und in der Websteinzeit dem Wiedergeben von Videos durch Flash absieht. HTML5 und die dazugehörenden JavaScript-APIs decken doch schon alle möglichen und unmöglichen Anwendungsfälle ab. Wieso also noch was Neues erfinden? Vor allem, wo doch jede neue Funktionalität immer auch die Angriffsfläche erhöht, die man doch eigentlich möglichst klein halten möchte.

Die Antwort ist ganz einfach: Wieso nicht? Vielleicht ist das Neue ja besser als alles Alte. Ob das so ist erfahren Sie in meinem Artikel auf entwickler.de.

Carsten Eilers