DOM XSS

Was ist DOM XSS?

DOM-basiertes XSS ist das Cross-Site-Scripting, das Ihr Server nie sieht. Die Payload befindet sich im URL-Fragment, document.referrer oder dem Inhalt einer postMessage -Nachricht, und clientseitiges JavaScript schreibt sie in innerHTML . Serverseitige Filter und Web Application Firewalls können diesen clientseitigen Datenfluss nicht prüfen. Sie packen eine img onerror -Payload in einen Freigabelink für einen Notiz-Viewer, öffnen ihn selbst, verfolgen den Fluss von der Quelle zum Sink und beheben den Fehler mit textContent , sodass der Browser einen Textknoten erzeugt, statt Markup zu parsen.

Was Sie lernen in DOM XSS

• Das Muster von Quelle und Sink erkennen: Eine vom Angreifer kontrollierte DOM-Quelle (location.hash, document.referrer, postMessage) liefert Daten an einen gefährlichen DOM-Sink (innerHTML, eval, document.write)
• Erklären, warum das URL-Fragment den Server nicht erreicht und weshalb WAFs und serverseitige Filter DOM-XSS nicht sehen
• Den gefährlichen Sink (innerHTML) durch einen sicheren (textContent) ersetzen, statt serverseitig zu filtern oder Eingaben umzuschreiben
• DOM XSS anhand des Datenflusses und des erforderlichen Korrekturorts von Reflected und Stored XSS unterscheiden
• Nach dem Entdecken eines Fehlers die Codebasis auf weitere Pfade von unsicheren Quellen zu gefährlichen Sinks prüfen

DOM XSS — Trainingsschritte

1. Tool zum Teilen von Notizen öffnen

   Heute nimmt Bob Tideline Federal ins Visier. Die Mitarbeitenden teilen kurze Notizen über ein internes Tool. Sie schreiben eine Notiz, das Tool erstellt einen Link, und alle, die ihn öffnen, lesen die Notiz im Browser. Bob öffnet den Editor, um zu sehen, wie aus einer Notiz ein Link wird.

2. Normale Notiz teilen

   Zunächst teilt Bob eine gewöhnliche Notiz, um zu sehen, wie das Tool einen Link erstellt. Der Notiztext wird direkt in den Link eingebettet.

3. Die Notiz steckt im Link

   Hier ist der Freigabelink. Die gesamte Notiz steht darin, im Teil nach # . Wenn jemand den Link öffnet, liest der Viewer dieses Fragment und rendert es. Die Notiz erreicht den Server von Tideline nie.

4. Test-Payload erstellen

   Der Viewer fügt alles, was die Notiz enthält, als HTML in die Seite ein. Deshalb schreibt Bob eine Notiz, die keine echte Notiz ist: ein Bild-Tag mit einer nicht ladbaren Quelle und einem onerror -Handler. Schlägt das Laden des Bildes fehl, läuft der Handler und führt den darin enthaltenen Code im Browser der Person aus, die den Link öffnet. Zunächst nutzt er den einfachsten möglichen Nachweis, ein schlichtes alert(1) , um zu bestätigen, dass sein Code überhaupt läuft.

5. Payload testen

   Bevor Bob die Payload für den Angriff einsetzt, öffnet er seinen eigenen Link in der Vorschau, um zu prüfen, ob sie ausgelöst wird. Die Vorschau öffnet die Notiz genau so, wie Empfänger sie sehen würden. Sobald der Viewer sie lädt, erscheint der Dialog. Sein Code läuft im Browser, genau wie geplant.

6. Payload für den Angriff vorbereiten

   Der Test war erfolgreich. Bob kehrt zum Editor zurück und ersetzt den harmlosen Alarm durch Code, der das Sitzungscookie der besuchenden Person liest – den Wert, mit dem ihre Anmeldung aufrechterhalten wird. Bei einem echten Angriff würde die Payload das Cookie unbemerkt an Bobs Server senden. Hier zeigt ein Dialog den gestohlenen Wert, damit Sie sehen, was der Code erfasst.

7. Link an ein Opfer senden

   Bob sendet den präparierten Link per E-Mail an Alice, eine Ingenieurin bei Tideline, die den ganzen Tag geteilte Notizen öffnet. Die Nachricht ist als Notiz vor ihrer morgendlichen Besprechung getarnt, daher hat sie keinen Grund zu zögern.

8. Eine geteilte Notiz trifft ein

   Bobs E-Mail ist unterwegs. Sie verantworten den Viewer-Code des Tools zum Teilen von Notizen, und kurz vor Ihrer Besprechung um 10:00 trifft eine geteilte Notiz in Ihrem Posteingang ein. Öffnen Sie die E-Mail und anschließend die Notiz.

9. Geteilte Notiz öffnen

   Nichts wirkt verdächtig, daher öffnen Sie die Notiz wie Dutzende andere auch.

10. Die Notiz stiehlt Ihre Sitzung

    Sobald die Notiz geladen wurde, erschien dieses Pop-up in Ihrem Browser. Es zeigt Ihr eigenes Session-Cookie – das Token, das Ihre Anmeldung aufrechterhält. Sie haben nichts angeklickt und nichts eingegeben. Die geteilte Notiz enthielt ein Skript, das gerade Ihre Sitzung ausgelesen hat und sie direkt an einen Angreifer hätte senden können. Das ist eine vollständige Kontoübernahme durch das Öffnen eines einzigen Links. Es konnte sid nur lesen, weil diesem Cookie HttpOnly fehlt; mit diesem Attribut könnte das Skript auf der Seite weiterhin in Ihrem Namen handeln, das Cookie aber nicht lesen.