Reflected XSS

Was ist Reflected XSS?

Reflected XSS versteckt sich in der URL. Auf dem Server wird nichts platziert: Ein präparierter Link führt das Skript des Angreifers auf Ihrer eigenen Origin in der angemeldeten Sitzung des Opfers aus. Sie ersetzen den Suchbegriff eines Shops durch eine img onerror -Payload und beobachten, wie sie in der Ergebnisüberschrift ausgeführt wird. Dann öffnen Sie den Such-Handler, finden den ohne Escaping in das Antwort-HTML eingefügten Suchbegriff, escapen ihn bei der Ausgabe und zeigen dieselbe Payload als inaktiven Text an. Eine Blockliste für script -Tags erkennt diesen Angriff nicht.

Was Sie lernen in Reflected XSS

• Reflected XSS von Stored XSS unterscheiden: Die URL ist der Zustellkanal und jedes Opfer muss den präparierten Link des Angreifers öffnen
• Im Handler-Code erkennen, wo ein URL-Parameter in die HTML-Antwort übernommen wird
• HTML-Escaping an der Rendering-Grenze als primären Schutz anwenden, nicht WAF-Blocklisten oder Eingabebereinigung
• Verstehen, warum eine img-onerror-Payload auch ohne script-Tag ausgeführt wird und warum Blocklisten für script-Tags versagen
• Erkennen, dass das Ausrollen der Lösung die Ausführung neutralisiert, nicht die Zustellung: Der Phishing-Link existiert weiterhin

Reflected XSS — Trainingsschritte

1. Die Storesuche finden

   Heute hat Bob Vellora im Visier, einen Online-Marktplatz mit vielen angemeldeten Kunden. Er öffnet die öffentliche Storesuche, um ihr Verhalten zu prüfen. Ein Suchfeld, das eine Anfrage in die Seite zurückschreibt, ist das Erste, was ein Angreifer untersucht.

2. Eine normale Suche ausführen

   Beobachten Sie zunächst, wie sich die Funktion für echte Käufer verhält. Führen Sie eine normale Produktsuche aus. Der Store zeigt passende Artikel an und wiederholt Bobs Suchbegriff in der Ergebnisüberschrift.

3. Die Abfrage wird reflektiert

   Bobs genauer Suchbegriff erscheint direkt in der Ergebnisüberschrift, und die Adressleiste enthält ihn nun als q -Parameter. Gefährlich wird diese Reflexion nur, wenn die Seite den Wert bei der Ausgabe nicht escaped. Ob das geschieht, zeigt ein Test mit einem Zeichen, das der Browser als Markup versteht.

4. Das Escaping prüfen

   Bob prüft die zurückgespiegelte Eingabe mit einem klassischen Test: einem Bild-Tag mit fehlerhafter Quelle und einem onerror -Handler, der ein harmloses alert(1) auslöst. Escaped die Seite die Abfrage, erscheint dies als Klartext in der Überschrift. Andernfalls baut der Browser ein echtes Tag und der Alert wird ausgelöst.

5. Die Schwachstelle ist ausnutzbar

   Der Alert wurde ausgelöst. Die Seite escaped die Abfrage nicht und führt daher jedes Markup aus, das die URL enthält. Das harmlose alert(1) war nur die Bestätigung. Eine echte Payload öffnet keinen Dialog. Sie läuft unbemerkt und stiehlt den Session-Cookie, sofern dieser per Skript lesbar ist.

6. Präparieren und phishen

   Bob ersetzt den Alert durch einen Cookie-Stealer, der die Sitzung an seinen eigenen Server übermittelt, verpackt ihn in einen Vellora -Suchlink, damit er auf der vertrauenswürdigen Store-Domain läuft, und versteckt ihn hinter einer freundlichen Belohnung. Anschließend schickt er ihn an eine echte Mitarbeiterin, deren Sitzung sich zu stehlen lohnt: Alice. Menschen vertrauen Links zum Store ihres eigenen Unternehmens.

7. Eine unerwartete Prämie

   Eine Prämien-E-Mail landet in Ihrem Posteingang. Sie wirkt, als käme sie von Vellora, und der Button verweist auf den Store, den Sie täglich nutzen. Nichts ist offensichtlich verdächtig.

8. Die Prämie einlösen

   Der Link öffnet Velloras eigenen Store und wirkt daher sicher. Klicken Sie darauf, um die Prämie einzulösen.

9. Was der Link tatsächlich ausführte

   Die Seite zeigt nur Velloras Suche, mit einem defekten Bild anstelle der Ergebnisüberschrift. Der q -Parameter des Links enthielt jedoch ein Skript. Es lief beim Rendern der Seite sofort, las Ihren Session-Cookie und übermittelte ihn an den Angreifer. Es gab keinen Dialog. Das defekte Bild ist die einzige Spur. Das funktionierte nur, weil dem Session-Cookie von Vellora HttpOnly fehlt; mit diesem Attribut könnte das Skript auf der Seite weiterhin in Ihrem Namen handeln, das Cookie aber nicht lesen.

10. Ihre Sitzung wurde übernommen

    Minuten später schlägt Security Operations Alarm. Der von Ihnen geöffnete Link hat Ihren eigenen Store gegen Sie gewendet, und nun besitzt jemand anderes Ihre Sitzung. Die Seite, über die Ihre Sitzung übernommen wurde, ist neben dem Alarm weiterhin geöffnet. Sie verantworten diesen Code. Lesen Sie den Alarm und beheben Sie anschließend die Grundursache.