Abwehr von Injection-Angriffen

XSS ist eine der häufigsten Angriffsarten

Cross-Site-Scripting (XSS)-Angriffe sind nach der Liste der häufigsten Angriffe auf Webanwendungen, der OWASP Top Ten, die dritthäufigste Angriffsart. Die Liste wird alle drei Jahre vom Open Web Application Security Project (OWASP) erhoben.

Angreifer können mit XSS vielfältigen Schaden anrichten

Grundsätzlich beschreibt XSS einen Angriff, bei dem es dem Angreifer gelingt, innerhalb einer Webseite fremdes Javascript auszuführen. Da das Einbinden von fremdem Javascript eine grundsätzlich gewollte und weit verbreitete Art der Programmierung ist, kann der Angriff meistens nicht durch einfache Maßnahmen abgewehrt werden.

Im Gegensatz zu vom Seitenbetreiber gewollten JavaScript-Codeabschnitten wird XSS-JavaScript für verschiedene bösartige Zwecke eingesetzt.

Ausspielen von Exploit-Kits. Das sind Bibliotheken, die den Browser des Nutzers nach Schwachstellen untersuchen, um auf dem Rechner der Nutzers bösartige Software zu installieren.
Umleiten der Webseitenbesucher auf Webseiten mit ungewollten Inhalten.
Defacement, Verunstalten der Webseite zum Zwecke der Sabotage oder der Gewinnung der öffentlichen Aufmerksamkeit.
Diebstahl von Cookies, um an die darin gespeicherten Nutzerdaten zu kommen. Hierfür wird auch oft das Cross-Site-Tracing verwendet, das eine Variante des Cross-Site-Scriptings ist.

XSS ist eine Spezialform einer lnjection

Letztendlich ist Cross-Site-Scripting eine Spezialform der Angriffsklasse der lnjections. Angreifer können ihre Ziele nicht nur durch Einschleusen von Javascript-Code in Webseiten erreichen, sondern sie können zum Beispiel auch Schaden anrichten, indem ungewollter html-Code in ein html-Dokument eingeschleust wird.

Einem Sicherheitsforscher ist es auf diese Weise gelungen, SSL-Zertifikate fremder Webseiten zu erlangen. Hierfür hat er den HTML-Code einer E-Mail der Zertifizierungsstelle an den Besitzer der Webseite so umgestaltet, dass dieser unwissentlich das vom Angreifer beantragte SSL-Zertifikat bestätigt. Aber auch andere Web-Sprachen wie XML, CSS, E-Mail-Header und HTTP-Header waren bereits für kreative lnjection-Angriffe anfällig.

Escaping von Ausgabedaten als Gegenmaßnahme

Eine der wichtigsten Maßnahmen, um verschiedenen Arten an lnjection-Angriffen abzuwehren ist es, alle Daten vor der Ausgabe zu überprüfen und entsprechend zu filtern, also ein Escaping der Ausgabedaten durchzuführen.

Brandbox wendet einen Filter auf alle HTTP-Anfragen an, sodass Schadhafter Code nicht per HTTP transportiert werden kann. Falls es notwendig ist auf HTTP-Daten zuzugreifen, muss das mit dem HTTP-Objekt geschehen.

Escaping von HTTP-Anfragen

$http = http\request::get();
echo $http->getString('<script>alert(1);</script');

// echo's "alert(1);"

Escaping in Handlebars

Escaped: {{content}}
Nicht escaped: {{{content}}}

HTTP-Security Header verwenden

HTTP-Security-Header können in brandbox konfiguriert werden und sollten nicht abgeschaltet werden.

Diverse Header, die standardmäßig aktiviert sind

# Aktivieren der Browser XSS-Blacklist
X-XSS-Protection: 1; mode=block

# Frames verbieten
X-Frame-Options: deny

# Typeninterpretation deaktivieren
X-Content-Type-Options: nosniff

# Content-Security-Policy aktivieren
Content-Security-Policy-Report-Only: report-uri /public?execute=...; 
default-src 'none'; connect-src 'self'; style-src  'unsafe-inline' 'self'; 
script-src  'unsafe-eval' 'self' ...; 
img-src 'self' data:; media-src 'self' *.youtube.com; font-src 'self';

# Same Origin Policy aktivieren
Access-Control-Allow-Origin: https://local.brandbox.de/

# Mitsenden des Referrers verhindern
Referrer-Policy: no-referrer

# HTTP Strict Transport Security aktiv
Strict-Transport-Security: max-age=0;includeSubDomains;preload

Content Security Policy - Report

Standardmäßig ist in Brandbox das Reporting für die Content Security Policy aktiviert. Als Ziel für die Reportings wird ein zentraler Sammelservice "csp.brandbox.host" angegeben.

Die Konfiguration der Report-URI erfolgt über die Security-Header Konfiguration.