Reflektiertes XSS

Was ist Reflektiertes XSS?

Reflektiertes Cross-Site-Scripting versteckt sich in der URL. Es wird nichts auf dem Server platziert: Ein manipulierter Link führt das Skript des Angreifers auf Ihrem eigenen Ursprung aus, innerhalb der angemeldeten Sitzung des Opfers. Sie ersetzen den Suchbegriff eines Shops durch eine img onerror -Nutzlast und beobachten, wie die Ergebnisüberschrift ihn ausführt. Dann öffnen Sie den Suchhandler, finden die im Antwort-HTML verkettete Abfrage, maskieren sie an der Rendering-Grenze und geben dieselbe Nutzlast als inaktiven Text wieder. Eine Sperrliste, die nach script -Tags sucht, sieht dieses nie.

Was Sie lernen in Reflektiertes XSS

• Reflected XSS von Stored XSS unterscheiden: Die URL ist der Zustellkanal und jedes Opfer muss den präparierten Link des Angreifers öffnen
• Den Reflection-Punkt in einer URL-zu-HTML-Antwortpipeline durch Lesen des Handler-Codes finden
• 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

Reflektiertes 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

   Der genaue Suchbegriff von Bob erscheint direkt in der Ergebnisüberschrift, und die Adressleiste enthält ihn nun als q -Parameter. Diese Reflection ist nur gefährlich, wenn die Seite den Wert beim Ausgeben nicht escaped. Das lässt sich nur prüfen, indem man einen vom Browser als Markup behandelten Wert einspeist.

4. Das Escaping prüfen

   Bob prüft die Reflection 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, sondern läuft unbemerkt und stiehlt den Session-Cookie des Besuchers.

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.

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.