Hallo Freunde, heute zeige ich Ihnen die Schritte zum Erkennen einer Schwachstelle, auf die ich bei Webanwendungssicherheitstests in meinem Projekt namens Saka Reflected XSS (Referer) gestoßen bin, und zum Ausnutzen dieser Schwachstelle.

Was ist XSS?

Detaillierte Informationen zur XSS-Schwachstelle finden Sie im folgenden Artikel.

Ausführen der Anwendung

Docker

docker pull erdemstar/saka:reflected-xss-referer
docker run -d -p 80:80 erdemstar/saka:reflected-xss-referer

git clone https://github.com/ErdemStar/Saka
cd reflected-xss-referer
- mouse click on reflected-xss-input.sln
- devenv reflected-xss-input.sln (CMD)

Wenn wir die Anwendung zum ersten Mal öffnen, werden wir von einer Seite wie der folgenden begrüßt. Durch Klicken auf die Schaltfläche „Angreifen“ auf der Seite werden wir zu dem Teil weitergeleitet, den wir testen möchten.

Wenn wir zur Seite „Angriff“ gelangen, stehen die Felder „Name“ und „Nachricht“ zur Verfügung. Wenn diese Felder ausgefüllt sind und die Anfrage gesendet wird, wird davon ausgegangen, dass keine Änderung auf der Seite erfolgt.

Da es auf der UI-Seite keine Änderung gibt, schauen wir uns die GET- und POST-Anfrage genauer an.

Es versteht sich, dass GET Request verwendet wird, um die Angriffsseite direkt abzurufen, ohne Daten vom Benutzer zu erhalten.

Obwohl davon ausgegangen wird, dass die POST-Anfrage dazu verwendet wird, den Namen und die Nachrichteninformationen zu senden, die sie vom Benutzer erhalten hat, wird bei der Überprüfung des Textteils festgestellt, dass sie keinen solchen Zweck hat, sondern lediglich ein Feld mit dem Namen „Referer“ an den sendet Backend.

Die an die Anwendung gesendete POST-Anfrage wird erstellt, wenn auf die Schaltfläche des Formulars auf der UI-Seite geklickt wird. Um genauer hinzusehen, sollte die Antwort mit GET Request untersucht werden.

Bei der Untersuchung des <form> -Tags der mit der GET-Anfrage erhaltenen Antwort wird festgestellt, dass die Namens- und Nachrichtenteile leer sind und dass eine Eingabe namens „ referer “ und der ihr zugewiesene Wert vorhanden sind.

Es wurde davon ausgegangen, dass der Grund, warum das Eingabeelement auf der Benutzeroberfläche nicht sichtbar ist, in der Einstellung von type=hidden liegt .

Schauen Sie sich die GET-Anfrage an, es kann überprüft werden, ob die „http://localhost/„Der dem Referrer in der Antwort zugewiesene Wert stammt wie folgt aus der Anfrage.

Wenn man sich das Referer-Feld in der GET-Anfrage etwas genauer ansieht, erkennt man anhand der Antwort, dass eine Eingabereflexion vorhanden ist.

Es wurde beobachtet, dass mit der POST-Anfrage, die der Anfrage in der GET-Anfrage ähnelt, nicht das gleiche Ergebnis erzielt wird.

Geistige Notizen

• Die Anwendung verwendet nicht den Namen und die Nachrichteninformationen, die der Benutzer über das Formular erhält.
• Wenn eine Anfrage mit GET an den /Home/Attack- Endpunkt gesendet wird , spiegeln sich die Daten im Header-Referrer-Feld der entsprechenden Anfrage auch in der Referrer- Eingabe in der Antwort wider.

Nachdem wir ausreichende Informationen über die Anwendung erhalten haben, fügen wir dem Referer- Wert, den wir senden , einige vom Browser zu interpretierende Zeichen hinzu, um die XSS-Schwachstelle auszunutzen.

Wenn wir den Inhalt der eingehenden Antwort prüfen, gehen wir davon aus, dass die Bewerbung den von uns erhaltenen Empfehlungswert ohne Sicherheitsüberprüfungen widerspiegelt.

Nachdem wir so viele Informationen über das Anwendungsverhalten erhalten haben, führen wir das Reflected XSS-Szenario für die Anwendung aus, wenn wir eine Anfrage wie die folgende an das Feld „ Referer“ senden.

Vielen Dank, dass Sie meinen Artikel gelesen haben. Ich hoffe, er war hilfreich für Sie. Unten lasse ich die Links zu meinen anderen Konzepten, die für Sie nützlich sein könnten.

Klicken Sie hier, um meine anderen Artikel über Web-Schwachstellen zu sehen. Verknüpfung