XSS-Attacken (Cross-Site-Scripting) gehört zu den häufigsten Angriffsformen im Internet. Angreifer versuchen dabei, nicht vertrauenswürdige Daten in vertrauenswürdige umzuwandeln und sich mit dem eingeschleusten Code Zugriff auf die Website zu verschaffen oder sensible Daten abzurufen. Erfahren Sie jetzt, wie Sie sich mit Content Security Policies (CSP) vor XSS-Attacken schützen.
Wie funktioniert ein XSS-Angriff?
Angenommen, Ihre Website integriert ein Eingabefeld, zum Beispiel für die Suche. Statt mit einem Text-String nach Inhalten zu suchen, kann ein Anwender auch ein Skript eingeben, zum Beispiel:
<script>alert();</script>
Dies ist die einfachste Form eines XSS-Angriffs. Wird die Alert-Box nach Klick auf Suche angezeigt, hat die Website den Skript-Code verarbeitet. Das bedeutet, dass Ihre Website den Code des Angreifers ausführt und als legitim betrachtet. Content Security Policies können das Ausführen von Inline-Script-Blöcken verhindern.
Content Security Policies (CSP)
Die Content Security Policy ist ein Abwehrmechanismus, der das Ausführen von fremden Daten verhindert. Mit CSP können Sie per HTTP-Response-Headern definieren, welche Daten der Browser von wo laden kann. CSP blockiert sämtlichen Content, der nicht explizit in die Whitelist aufgenommen wurde. Der Browser prüft die CSP-Regeln und verhindert auf diese Weise bereits viele gängige Angriffsformen. Dazu gehört unter anderem das Einbetten fremder Ressourcen. So ist es möglich, das Ausführen von JavaScript-Dateien zu verhindern, die von einem anderen Webserver stammen. Der Standard-Eintrag sieht so aus:
Content-Security-Policy: default-src 'self'
Die Folge: Der Browser lädt ausschließlich Daten vom selben Webserver. Externe Videos von YouTube funktionieren nicht mehr. Genauso wenig lassen sich externe JavaScript-Bibliotheken laden und das Tracking mit Google funktioniert nicht mehr. Per Standardeinstellung blockt CSP alle Script-Blöcke.
Hashes
Ist CSP mit der Standard-Einstellung aktiviert und die Website integriert Inline-Script-Blöcke, zeigt die Konsole beim Laden der Website einen Fehler an:
Refused to execute inline script because it violates the following Content Security Policy: „default-scr ’self'“. Either the unsafe-inline keyword, a hash(’sha256-sdfjkhfdkjPsdfdfPsddsP‘), or nonce … is required to enable inline execution.
Das Script wird nicht geladen. Das Laden lässt sich mit dem
- „unsafe-inline“ Schlüsselwort,
- der Verwendung eines Hashes oder
- einer Nonce erlauben.
„unsafe-inline“ deaktiviert den Schutz komplett, in der Folge wird jedes Script ausgeführt – das ist nicht gewollt.
Sie können den SHA-256 Hash aus der Fehlermeldung kopieren und die CSP ändern:
Content-Security-Policy: default-src 'self'; script-src 'sha256-sdfjkhfdkjPsdfdfPsddsP'
Diese Lösung funktioniert gut. Der Hash des Script-Blocks bleibt immer gleich und mit der Codezeile wird erklärt, dass exakt diesem Script immer vertraut wird. Dieses Skript wird ausgeführt, alle anderen nicht.
Mit Hashes erstellen Sie also eine Whitelist für gewünschte Inline-Scripts. Hinweis: Jede Änderung am Code des Script-Blocks führt zu einem neuen Hash.
Nonces
Hashes funktionieren nur mit statischen Script-Blöcken. Es gibt allerdings Script-Blöcke mit dynamisch generiertem Content, der potenziell riskant sein kann. Ein Hash funktioniert nicht, da der Inhalt schlichtweg nicht bekannt ist. Zwar ließe sich der Hash ebenfalls dynamisch erstellen, das führt jedoch eher zu Chaos und macht die Wartung schwierig.
Die geeignete Alternative sind Nonces. Eine Nonce ist eine zufällige Nummer, die einmal verwendet wird. Statt, wie bei Hashes, einen spezifischen Script-Block in die Whitelist aufzunehmen, können Sie mit Nonces den gesamten Script-Block in die Liste erlaubter Scripte aufnehmen – unabhängig vom Inhalt. Der Code mit einer Nonce sieht so aus:
Content-Security-Policy: default-src 'self'; script-src 'nonce-1asdwefxdsfacJptoIGFP3Nd'
<script type="text/javascript" nonce="1asdwefxdsfacJptoIGFP3Nd">
Der Wert in der CSP stimmt mit dem Attribut-Wert im Script-Tag überein. Nonces bieten auf diese Weise mehr Flexibilität. Bei dynamisch generiertem Script-Content bleibt jedoch das Risiko eines Angriffs bestehen.
Zusammenfassung
Mit CSP schützen Sie Ihre Website und Seitenbesucher vor Angriffen.
- Ohne CSP wird jedes Inline-Script ausgeführt.
- Mit Angabe einer Nonce führt die Website ein beliebiges Script innerhalb des Blocks mit dem Nonce-Wert aus.
- Ein Hash erlaubt das ausführen des exakten Scripts.
- CSP in der Default-Einstellung blockiert Inline-Scripte komplett.
Fehler in der CSP haben zur Folge, dass die Website nicht mehr richtig funktioniert. Daher sollten Sie Berichte mit einem Service wie Report URI loggen. Lesen Sie in diesem Zusammenhang auch unseren Artikel zum Thema Cross-Site Scripting mit Script Gadgets.
Bildnachweis: Titelbild von Gerd Altmann auf Pixabay
