Einführung in Content-Security-Policy (CSP)

Injektionsschwachstellen, die in der OWASP Top 10 als A03:2021 eingestuft sind, stellen eine erhebliche Bedrohung für die Web-Sicherheit dar. Sie treten auf, wenn böswillige Daten einen Interpreter manipulieren, was zu einem unbefugten Datenzugriff oder zur Ausführung schädlicher Befehle führen kann. Cross-Site Scripting (XSS), eine häufige Form der Injektion, ermöglicht es Angreifern, bösartige Skripte in den Browsern der Benutzer auszuführen und so die Integrität von Daten und Websites zu gefährden.

Content Security Policy (CSP) bietet einen wichtigen Schutz gegen solche Schwachstellen. Sie ermöglicht es Entwicklern, vertrauenswürdige Quellen für ausführbare Skripte zu definieren und so XSS- und andere Injektionsangriffe abzuwehren. In diesem Blog-Beitrag wird die Rolle von CSP bei der Stärkung von Webanwendungen gegen diese weit verbreiteten Cyber-Bedrohungen näher beleuchtet.

Cross-Site-Scripting ist nur der Anfang

Cross-Site Scripting (XSS) ist eine weit verbreitete Sicherheitslücke, die grob in zwei Typen unterteilt werden kann: reflektiertes (reflected) und gespeichertes (stored) XSS. Reflektierte XSS-Angriffe treten auf, wenn ein bösartiges Skript über eine Benutzereingabe wie ein Suchformular eingeschleust wird, das von Webanwendungen sofort zurückgegeben wird. Diese Art von Angriffen erfolgt in der Regel über einen Link, der das bösartige Skript enthält und der, wenn der Benutzer darauf klickt, das Skript im Browser des Benutzers ausführt.

Beim gespeicherten XSS, auch bekannt als persistentes XSS, wird hingegen ein Skript injiziert, das auf dem Server oder in der Datenbank gespeichert ist. Dieses Skript wird dann den Benutzern als Teil des regulären Inhalts angeboten. Ein häufiger Vektor für gespeichertes XSS ist ein Kommentar zu einem Blogbeitrag, der ein Skript enthält.

Entschlüsselung von Cross-Site Scripting: Ein genauerer Blick auf Reflected und Stored XSS

Diese Schwachstellen können besonders schädlich für ein Content Management System (CMS) sein. Wenn ein Angreifer einen XSS-Angriff innerhalb eines CMS erfolgreich ausführt, kann er möglicherweise die Sitzung eines Redakteurs oder Administrators entführen. Dies wird erreicht, indem ein Skript eingeschleust wird, das Session-Token oder Cookies abfängt und an den Angreifer sendet. Mit diesen Anmeldeinformationen kann der Angreifer unbefugten Zugriff auf das CMS mit denselben Berechtigungen erlangen. Dies kann zu unbefugten Inhaltsänderungen, Datenverletzungen oder zur weiteren Verbreitung des Angriffs innerhalb der CMS-Benutzerbasis führen.

CSP als Retter in der Not

Die Content Security Policy spielt eine entscheidende Rolle bei der Minderung solcher Risiken, indem sie die Quellen einschränkt, aus denen Skripte geladen werden können, und so die Ausführung nicht autorisierter Skripte verhindert. Durch die Implementierung einer robusten CSP können Website-Administratoren die Wahrscheinlichkeit und die Auswirkungen von sowohl reflektierten als auch gespeicherten XSS-Angriffen in einer CMS-Umgebung erheblich verringern.

CSP wird über HTTP-Header implementiert, die den Webbrowsern Anweisungen zur sicheren Skriptausführung geben. Der Content-Security-Policy-Header definiert Regeln darüber, von wo Ressourcen wie Skripte und Stylesheets geladen werden können.

Die Struktur eines CSP Headers

Hier ein typisches Beispiel für einen CSP-HTTP-Header, der Google Tag Manager, lokale Stylesheets, Schriftarten und JavaScript zulässt, während Inline-JavaScript nicht erlaubt ist:

1
2
3
4
5
6
7

Content-Security-Policy: default-src 'self';
  script-src 'self' https://www.googletagmanager.com;
  style-src 'self' 'unsafe-inline';
  font-src 'self https://fonts.googleapis.com';
  connect-src 'self' https://www.google-analytics.com;
  img-src 'self' https://www.google-analytics.com;
  frame-src 'self' https://www.googletagmanager.com;

Diese Richtlinie sieht Folgendes vor:

1

default-src 'self'

1

script-src 'self' https://www.googletagmanager.com

1

style-src 'self' 'unsafe-inline'

1

font-src 'self https://fonts.googleapis.com'

1

connect-src 'self' https://www.google-analytics.com

1

img-src 'self' https://www.google-analytics.com

1

frame-src 'self' https://www.googletagmanager.com

CSP Support - Stufe 1, Stufe 2 und Stufe 3

Bis 2023 wird das CSP weiter ausgebaut und die ursprüngliche Norm um verschiedene Elemente erweitert. Mit jeder CSP-Stufe werden anspruchsvollere Sicherheitsmerkmale eingeführt. CSP Stufe 1 bietet den grundlegenden Rahmen für die Definition vertrauenswürdiger Inhaltsquellen. CSP Stufe 2 führt mehr Richtlinien ein und bietet strengere Möglichkeiten zur Durchsetzung von Richtlinien, während CSP Stufe 3 dies mit noch mehr Richtlinien und Verbesserungen, wie z. B. einer verfeinerten Kontrolle über die Ausführung von Inline-Skripten, weiter verfeinert.

Die Unterstützung für CSP und seine verschiedenen Stufen variiert zwischen den einzelnen Webbrowsern:

Google Chrome: Chrome unterstützt CSP seit Version 25. Ursprünglich wurde CSP Level 1 unterstützt, später kam die Unterstützung für CSP Level 2 und 3 hinzu, die eine detailliertere Kontrolle über Skript- und Style-Quellen bieten.

Mozilla Firefox: Firefox unterstützt CSP seit der Version 23. Wie Chrome hat er seine Unterstützung schrittweise von CSP 1 auf CSP 3 erweitert, um sich an die sich entwickelnden Web-Sicherheitsstandards anzupassen.

Safari (Apple): Safari begann seine Unterstützung für CSP mit Version 7 und hielt sich zunächst an die Richtlinien der Stufe 1. Nachfolgende Versionen haben diese Unterstützung erweitert und weitere Funktionen der CSP-Stufen 2 und 3 integriert.

Microsoft Edge: Der ursprüngliche Edge-Browser, der auf EdgeHTML basiert, unterstützte CSP bereits in seinen frühen Versionen und orientierte sich eng an den Standards der CSP-Stufen 1 und 2. Der 2020 veröffentlichte, auf Chromium basierende Edge unterstützt ähnlich wie Chrome die CSP-Stufen bis 3.

Internet Explorer: Der Internet Explorer bietet ab Version 10 eine begrenzte Unterstützung für CSP. Seine Implementierung ist jedoch weniger umfassend als bei anderen modernen Browsern, insbesondere in Bezug auf die CSP-Stufen 2 und 3.

Zusammenfassend lässt sich sagen, dass die meisten modernen Webbrowser CSP verstehen und durchsetzen, mit Unterschieden im Grad der Unterstützung und Implementierung. Dies macht CSP zu einem wichtigen Werkzeug im Arsenal des Webentwicklers, um die Ausführung nicht autorisierter Skripte zu verhindern und so die Risiken im Zusammenhang mit XSS und anderen Injektionsschwachstellen zu mindern.

Hinweis: Bei der Verwendung von älteren Browsern oder eingebetteten Browsern in einer Smartphone-App kann es zu Regelverstößen kommen: Wenn du den In-App-Browser der Facebook-App deines Smartphones verwendest, injiziert Facebook immer zusätzlichen JavaScript-Code, der deine CSP-aktivierte Website beschädigt. Ältere Browser, z. B. aus dem Jahr 2017, verstehen Ihre CSP-Regeln möglicherweise nicht und machen Ihre Seiten ebenfalls unbrauchbar. Es wird dringend empfohlen, die CSP-Sicherheit und -Strenge beizubehalten und beides nicht aus Gründen der Kompatibilität mit älteren Browsern zu reduzieren.

Weitere CSP-Funktionen

Während CSP mit dem bestehenden Format von oben sehr flexibel ist, gibt es ein paar raffinierte Ergänzungen, die bei speziellen Fällen und dynamischeren Anwendungsfällen helfen:

Nur-Bericht-Modus

Was ist das?

• Der Report-Only-Modus im CSP ermöglicht es Ihnen, eine Richtlinie zu testen, ohne sie durchzusetzen. Dieser Modus sendet Berichte über Richtlinienverstöße an eine bestimmte URL, blockiert aber keine Inhalte, die gegen die Richtlinie verstoßen.

Beispiel für die Verwendung:

Content-Security-Policy-Report-Only: script-src 'self'; report-uri /csp-violation-report-endpoint

• Hier befindet sich der CSP im Report-Only-Modus. Verstöße gegen die Richtlinie script-src 'self' werden an /csp-violation-report-endpoint gemeldet, Skripte aus anderen Quellen werden jedoch weiterhin ausgeführt.

Wann wird sie verwendet?

• Sie wird verwendet, wenn eine neue Richtlinie getestet wird, um sicherzustellen, dass sie die Funktionalität der Website nicht beeinträchtigt. Nachdem Sie sich vergewissert haben, dass keine rechtmäßigen Inhalte blockiert werden, können Sie zur Durchsetzung der Richtlinie übergehen.

Nonces

Was sind Nonces?

• Ein Nonce (eine einmalig verwendete Zahl) ist ein zufälliges Token, das verwendet wird, um bestimmte Inline-Skripte oder Stile auf die Whitelist zu setzen. Jedes Mal, wenn die Seite geladen wird, wird ein neuer Nonce-Wert erzeugt.

Beispiel für die Verwendung:

Content-Security-Policy: script-src 'nonce-XYZ123'

<script nonce="XYZ123"> ... </script>

• Hier wird nur das Skript-Tag mit der passenden Nonce XYZ123 zur Ausführung zugelassen.

Wann sollte man sie verwenden?

• Verwenden Sie Nonces, wenn Sie bestimmte Inline-Skripte oder Stile zulassen und gleichzeitig einen restriktiven CSP beibehalten müssen.

Hashes

Was sind sie und wann sollte man sie verwenden?

• Mit Hashes in CSP können Sie bestimmte Inline-Skripte oder Stile auf der Grundlage ihres kryptografischen Hash-Wertes auf die Whitelist setzen.
• Sie werden verwendet, wenn Sie statische Inline-Skripte oder -Stile haben, die Sie zulassen wollen, ohne auf die weniger sichere 'unsafe-inline'-Direktive zurückzugreifen.

Beispiel für die Verwendung:

Content-Security-Policy: script-src 'sha256-Base64EncodedHash'

<script> ... </script> <!-- Script content here must match the hash -->

• Der Hash (z. B. "sha256-Base64EncodedHash") muss mit dem Hash des Inhalts des Inline-Skripts übereinstimmen.

Woher kommen sie?

• Sie generieren den Hash aus dem Inhalt Ihres Inline-Skripts oder Stils. Tools und Browser-Entwicklerkonsolen können bei der Erzeugung dieser Hashes helfen.

Integrität von Subressourcen (SRI)

Was ist das?

• SRI ergänzt CSP, indem es eine weitere Verifizierungsebene für externe Ressourcen hinzufügt, die Ihre Website noch besser gegen potenzielle Manipulationen oder Angriffe absichert.
• Sie ermöglicht es Browsern, zu überprüfen, ob die von einem Server abgerufenen Ressourcen (wie JavaScript- oder CSS-Dateien) genau dem entsprechen, was der Server beabsichtigt hat.
• Es wird implementiert, indem ein kryptographischer Hash zu einem Ressourcen-Tag, wie einem Skript- oder Link-Tag, hinzugefügt wird.

Beispiel für die Verwendung:

<script src="https://example.com/example.js" 
integrity="sha384-Base64EncodedHash"
crossorigin="anonymous"></script>

• In diesem Beispiel ist sha384-Base64EncodedHash der base64-kodierte SHA-384-Hash der Datei example.js. Der Browser berechnet den Hash der abgerufenen Datei und vergleicht ihn mit diesem Wert. Wenn sie nicht übereinstimmen, wird die Datei nicht ausgeführt oder angewendet.

Wann und warum sollte man es verwenden?

• Verwenden Sie SRI beim Laden von Ressourcen aus externen Quellen, insbesondere CDNs, um deren Integrität sicherzustellen.
• Es ist besonders nützlich, um sich vor der Kompromittierung von Drittanbietern zu schützen. Wenn ein CDN oder eine externe Quelle kompromittiert und der Inhalt verändert wird, verhindert SRI, dass der veränderte Inhalt geladen wird.

Beschränkungen und Überlegungen:

• SRI ist nur wirksam, wenn das Integritätsattribut sicher übermittelt wird. Wenn ein Angreifer den HTML-Code Ihrer Website verändern kann, kann er auch die SRI-Attribute verändern.
• Es eignet sich nicht für Ressourcen, die sich häufig ändern sollen, da jede Änderung an der Ressource eine Aktualisierung des Hashes im Integritätsattribut erfordert.

Verwendung von 'unsafe-hashes'

Was ist das und was bewirkt es?

• Die 'unsafe-hashes'-Direktive in CSP erlaubt bestimmte Inline-Event-Handler (wie onclick, onsubmit usw.), während andere Inline-Skripte blockiert werden.
• Sie erhöht die Sicherheit, indem sie nur bestimmte Inline-Event-Handler zulässt, ohne alle Inline-Skripte zu aktivieren.
• Unsafe-hashes" wurde mit CSP Level 3 eingeführt und hilft bei der Bewältigung von Szenarien in Kombination mit "strict-dynamic", insbesondere wenn Sie externe Dienste wie Google Maps auf Ihrer Website zulassen.

Beispiel für die Verwendung:

Content-Security-Policy: script-src 'self' 'unsafe-hashes' 'sha256-Base64EncodedHash'

• Diese Richtlinie erlaubt Skripte desselben Ursprungs, bestimmte Inline-Ereignishandler, die dem Hash entsprechen, blockiert aber andere Inline-Skripte.

Schlussfolgerung

• Der Nur-Bericht-Modus wird zum Testen von Richtlinien verwendet.
• Nonces erlauben bestimmte Inline-Skripte/Stilarten und eignen sich hervorragend für dynamische Inhalte.
• Hashes werden für statische Inline-Inhalte verwendet.
• SRI werden in Szenarien verwendet, in denen Sie für wichtige Skripte oder Stile auf externe Quellen angewiesen sind.
• unsafe-hashes" lässt selektiv bestimmte Inline-Event-Handler zu und bietet einen Mittelweg zwischen der vollständigen Zulassung von Inline-Skripten und der vollständigen Einschränkung.

Jedes dieser Tools und Direktiven dient einem bestimmten Zweck bei der Erstellung eines CSP, das die Sicherheitsanforderungen mit den funktionalen Anforderungen in Einklang bringt.

Eine hervorragende Ressource, um sich eingehend über CSP zu informieren, ist content-security-policy.com.

CSP: Mit großer Macht kommt große Verantwortung

Jetzt weißt du, dass du jedes XSS-Problem mit CSP auf deiner Website effektiv beseitigen kannst. Aber denk daran: CSP sollte auf deine spezifischen Bedürfnisse zugeschnitten und gründlich getestet werden, um sicherzustellen, dass es nicht versehentlich die Funktionalität deiner Website beeinträchtigt.

Denk auch daran, dass CSP zwar eine starke Sicherheitsmaßnahme ist, aber Teil einer umfassenden Sicherheitsstrategie sein sollte. Das Senden von CSP-Headern kann in der Web Application Firewall, in der Webserver-Konfiguration (z.B. Nginx oder Apache / htaccess-Datei) erfolgen, aber deine Anwendung sollte dies verstehen und unterstützen.

TYPO3 als Content Management System unterstützt das Rendering deiner Inhalte und deines Admin-Interfaces mit CSP seit Version 12, einschließlich einer Konfigurationsschnittstelle.