Hallo Freunde, heute zeige ich Ihnen die Schritte zum Erkennen einer Schwachstelle, auf die ich bei Webanwendungssicherheitstests in meinem Projekt namens Saka Reflected XSS (JS Variable) 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-js-variable
docker run -d -p 80:80 erdemstar/saka:reflected-xss-js-variable

git clone https://github.com/ErdemStar/Saka
cd reflected-xss-js-variable
- 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 Angriffsseite gelangen, werden wir mit einer Seite konfrontiert, auf der die Namensinformationen des Benutzers übernommen werden. Wenn wir in dieses Feld einen Namen schreiben und absenden, erhalten wir das folgende Ergebnis.

Um einen genaueren Blick auf die Anwendung zu werfen, wäre es hilfreich, die ein- und ausgehenden Anfragen über den Browser zu sehen.

Geistige Notizen

• Der vom Benutzer empfangene Wert wird im Namensparameter gespeichert und mit GET HTTP Verb gesendet.
• Die Anwendung zeigt den Wert, den sie vom Benutzer erhält, mithilfe der Zeilen 72–73–74 des oben geteilten Bildes an. Die Anwendung zeigt dem Benutzer die Daten im JS-Feld an.

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

Wenn wir den Inhalt der eingehenden Antwort prüfen, wird davon ausgegangen, dass der Antrag den von uns erhaltenen Namenswert ohne Sicherheitsüberprüfungen widerspiegelt.

Wenn hier die vom Benutzer empfangenen Daten zum Skript-Tag hinzugefügt werden, können sie mit zwei verschiedenen Methoden ausgenutzt werden.

1-Methode (HTML-Injektion)

Wenn die 73 in der Antwort zurückgegebenen Zeilen untersucht werden, verwendet die Anwendung indirekt die Javascript- Funktion inner.html , anstatt die vom Benutzer empfangenen Daten direkt in HTML hinzuzufügen und anzuzeigen. Hier kann ein XSS-Angriff durchgeführt werden, wenn eine Anfrage wie die folgende geworfen wird.

2-Methode (JS-Bypass)

Nach der Untersuchung von 73 Zeilen kann eine Anfrage mit einem Payload-Format ähnlich dem folgenden gesendet werden und verschiedene Javascript-Befehle können innerhalb des Skript-Tags ausgeführt werden.

<context>";//<payload>

Zu diesem Zeitpunkt wurde der JS-Befehl direkt ausführbar gemacht, indem eine einfache Anfrage wie folgt gestellt wurde.

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