Content Security Policy
Wusstest Du, dass deine Website mit einem einfachen Mittel vor einem der bekanntesten Injection-Angriffe besser geschützt werden kann? In diesem Blogpost stelle ich dieses Mittel vor: die Content Security Policy (CSP).
Sicherheitsrisiken für Webapplikationen
Laut den OWASP Top 10, einer im Security-Bereich angesehenen Liste von den 10 größten Security-Risiken für Webapplikationen, sind Injection-Angriffe ein großes Problem. In der aktuellsten Version der Liste, aus dem Jahr 2021, handelt es sich bei Injection-Angriffen um das drittgrößte Risiko.
Beim Besuch einer Website werden Ressourcen von verschiedensten Orten geladen. Wenn es Sicherheitslücken gibt, kann es sein, dass durch einen Angriff „böse“ Ressourcen eingebunden werden, die definitiv nicht auf die Website gehören. Wie kann ich als Entwickler und Server Admin sichergehen, dass nur die Ressourcen geladen werden, die auch dafür vorgesehen sind?
Sicherheit durch die Content Security Policy
Mit der Content Security Policy (kurz CSP) kann der Server einem Browser mitteilen, woher der Browser sich Ressourcen erwarten kann, die beim Besuch einer Website geladen werden. Sobald ein:e User:in die Website besucht, kann der Browser so erkennen, ob Ressourcen geladen werden, die nicht vorgesehen sind. Das hilft, die Angriffsfläche für Cross-Site-Scripting-Attacken (XSS) zu reduzieren und die Website dadurch sicherer zu machen.
Konfiguration der Content Security Policy
Die Content Security Policy kann entweder als http-Header durch die Serverkonfiguration oder alternativ direkt im HTML-Code durch einen <meta>-Tag mitgegeben werden.
Beispiel für eine Content Security Policy als http-Header (in Server-Konfiguration):
default-src ‚self‘; img-src ‚self‘ https://img.mywebsite.com; font-src https://google-fonts.com;Beispiel für eine Content Security Policy als Meta-Tag:
<meta http-equiv="Content-Security-Policy" content="default-src ‚self‘; img-src ‚self‘ https://img.mywebsite.com; font-src https://google-fonts.com;">Unterschiedliche Konfigurationsmöglichkeiten der CSP
Die vielen Konfigurationsmöglichkeiten der Content Security Policy erlauben einen genauen Zuschnitt auf den Anwendungsfall. Prinzipiell soll so wenig wie möglich, aber so viel wie nötig, durch die Content Security Policy zugelassen werden. Damit wird größtmögliche Sicherheit garantiert. Allerdings muss aufgepasst werden, dass benötigte Ressourcen nicht aus Versehen blockiert werden. Ansonsten kann es passieren, dass Features auf der Website nicht mehr funktionieren. Wenn beispielsweise die Cookie-Meldung durch einen externen Service bereitgestellt wird und dieser eine JavaScript-Datei auf der Website fordert, kann durch eine fehlende Ausnahme die JavaScript-Datei nicht geladen werden. Dann wird die Cookie-Meldung nicht angezeigt. Daraus folgt, dass wenn neue Ressourcen eingebunden werden sollen, die Content Security Policy ebenso angepasst werden muss. Je nachdem, wer die Ressourcen und wer die Content Security Policy pflegt, muss ein Developer oder Server-Administrator bei Inhaltsänderungen zugezogen werden.
Wie nun konkret eine Content Security Policy zugeschnitten auf den jeweiligen Anwendungsfall konfiguriert und damit eingeschränkt werden kann, woher die Ressourcen kommen dürfen, folgt im nächsten Blog.
Blogserie Content Security Policy
