Inhaltssicherheitsrichtlinie

Content Security Policy ( CSP ) ist ein Sicherheitsstandard für Computer, der eingeführt wurde, um Cross-Site-Scripting (XSS), Clickjacking und andere Code-Injection- Angriffe zu verhindern, die durch die Ausführung schädlicher Inhalte im Kontext vertrauenswürdiger Webseiten entstehen können . ^{[ 1 ]} Sie ist eine Kandidatenempfehlung der W3C- Arbeitsgruppe für Webanwendungssicherheit ^{[ 2 ]} und wird von modernen Webbrowsern weitgehend unterstützt . ^{[ 3 ]} CSP bietet Website-Betreibern eine Standardmethode, um die zulässigen Ursprünge von Inhalten zu deklarieren, die Browser auf der jeweiligen Website laden dürfen. Zu den abgedeckten Inhaltstypen gehören JavaScript , CSS , HTML-Frames , Web Worker , Schriftarten , Bilder, einbettbare Objekte wie Java-Applets , ActiveX , Audio- und Videodateien sowie weitere HTML5- Funktionen.

Der ursprünglich als „Content Restrictions“ bezeichnete Standard wurde 2004 von Robert Hansen vorgeschlagen ^{[ 4 ]} , erstmals in Firefox 4 implementiert und schnell von anderen Browsern übernommen. Version 1 des Standards wurde 2012 als W3C-Kandidatenempfehlung veröffentlicht ^{[ 5 ]} , und bereits 2014 folgten weitere Versionen (Level 2). Seit 2023 wird der Entwurf von Level 3 entwickelt, dessen neue Funktionen von Webbrowsern rasch übernommen werden ^{[ 6 ] .}

Die folgenden Headernamen werden im Rahmen experimenteller CSP-Implementierungen verwendet: ^{[ 3 ]}

• Content-Security-Policy– Standard-Headername, der im W3C-Dokument vorgeschlagen wurde. Google Chrome unterstützt dies ab Version 25. ^{[ 7 ]} Firefox unterstützt dies ab Version 23, ^{[ 8 ]} veröffentlicht am 6. August 2013. ^{[ 9 ]} WebKit unterstützt dies ab Version 528 (Nightly Build). ^{[ 10 ]} Die Unterstützung des Chromium-basierten Microsoft Edge ist ähnlich wie die von Chrome. ^{[ 11 ]}
• X-WebKit-CSP– veralteter, experimenteller Header, der 2011 in Google Chrome , Safari und anderen WebKit-basierten Webbrowsern eingeführt wurde. ^{[ 12 ]}
• X-Content-Security-Policy– Veralteter, experimenteller Header, eingeführt in Gecko-2- basierten Browsern (Firefox 4 bis Firefox 22, Thunderbird 3.3, SeaMonkey 2.1). ^{[ 13 ]}

Eine Website kann mehrere CSP-Header deklarieren, wobei auch Durchsetzungs- und Melde-Header gemischt werden können. Jeder Header wird vom Browser separat verarbeitet.

CSP kann auch innerhalb des HTML-Codes mithilfe eines Meta-Tags bereitgestellt werden , allerdings ist in diesem Fall seine Wirksamkeit eingeschränkt. ^{[ 14 ]}

Internet Explorer 10 und Internet Explorer 11 unterstützen ebenfalls CSP, allerdings nur die Sandbox-Direktive, und zwar mithilfe des experimentellen X-Content-Security-PolicyHeaders. ^{[ 15 ]}

Eine Reihe von Web-Frameworks unterstützt CSP, beispielsweise AngularJS ^{[ 16 ]} (nativ) und Django (Middleware). ^{[ 17 ]} Anleitungen für Ruby on Rails wurden auf GitHub veröffentlicht . ^{[ 18 ]} Die Unterstützung durch ein Web-Framework ist jedoch nur dann erforderlich, wenn der CSP-Inhalt vom Zustand der Webanwendung abhängt – etwa von der Verwendung des nonceUrsprungs. Andernfalls ist der CSP relativ statisch und kann von übergeordneten Webanwendungsebenen bereitgestellt werden , beispielsweise von einem Load Balancer oder Webserver .

Im Dezember 2015 ^{[ 19 ]} und Dezember 2016 ^{[ 20 ]} wurden einige Methoden zum Umgehen 'nonce'von Whitelisting-Ursprüngen veröffentlicht. Im Januar 2016 ^{[ 21 ]} wurde eine weitere Methode publiziert, die serverweites CSP-Whitelisting nutzt, um ältere und anfällige Versionen von JavaScript-Bibliotheken auszunutzen, die auf demselben Server gehostet werden (ein häufiges Problem bei CDN-Servern). Im Mai 2017 ^{[ 22 ]} wurde eine weitere Methode zur Umgehung von CSP mithilfe von Webanwendungs-Frameworks veröffentlicht.

Ist der Content-Security-PolicyHeader in der Serverantwort vorhanden, setzt ein konformer Client die deklarative Zulassungsrichtlinie durch. Ein Beispiel für das Ziel einer solchen Richtlinie ist ein strengerer Ausführungsmodus für JavaScript, um bestimmte Cross-Site-Scripting-Angriffe zu verhindern. In der Praxis bedeutet dies, dass eine Reihe von Funktionen standardmäßig deaktiviert sind:

• Inline- JavaScript- Code ^{[ a ]}
  • <script>Blöcke, ^{[ b ]}
  • DOM- Ereignisbehandler als HTML-Attribute (z. B. onclick)
  • Die javascript:Links
• Inline- CSS -Anweisungen
  • <style>Block ^{[ b ]}
  • styleden HTML-Elementen zugeordnet
• Dynamische JavaScript -Codeauswertung ^{[ c ]}
  • eval()
  • Zeichenkettenargumente für setTimeoutund setIntervalFunktionen
  • new Function()Konstruktor
• Dynamische CSS- Anweisungen
  • CSSStyleSheet.insertRule()Verfahren

Während die Verwendung von CSP in einer neuen Anwendung recht unkompliziert sein kann, insbesondere mit einem CSP-kompatiblen JavaScript- Framework, ^{[ d ]} erfordern bestehende Anwendungen möglicherweise eine Umstrukturierung oder eine Lockerung der Richtlinie. Empfohlene Vorgehensweise für CSP-kompatible Webanwendungen ist das Laden von Code aus externen Quelldateien ( <script src>), das Parsen von JSON anstatt dessen Auswertung und die Verwendung EventTarget.addEventListener()von zum Festlegen von Ereignisbehandlern. ^{[ 23 ]}

Wenn eine angeforderte Ressource oder die Ausführung eines Skripts gegen die Richtlinie verstößt, sendet der Browser eine Anfrage an den in ^{[ 24 ]} oder ^{[ 25 ]}POST angegebenen Wert, die Einzelheiten des Verstoßes enthält. report-urireport-to

CSP-Berichte sind standardisierte JSON- Strukturen und können entweder über die eigene API der Anwendung ^{[ 26 ]} oder über öffentliche CSP-Berichtsempfänger erfasst werden.

Im Jahr 2018 zeigten Sicherheitsforscher, wie man Fehlalarme an den in der Konfiguration festgelegten Empfänger sendet report-uri. Dies ermöglicht es potenziellen Angreifern, diese Alarme willkürlich auszulösen und ihre Wirksamkeit im Falle eines tatsächlichen Angriffs zu beeinträchtigen. ^{[ 27 ]} Dieses Verhalten ist beabsichtigt und kann nicht behoben werden, da der Browser (Client) die Meldungen sendet.

Gemäß dem ursprünglichen CSP-Verarbeitungsmodell (1.0) (2012–2013) ^{[ 28 ]} sollte CSP die Funktion von Browser-Add-ons oder -Erweiterungen, die vom Benutzer installiert wurden, nicht beeinträchtigen. Diese Eigenschaft von CSP hätte es ermöglicht, dass beliebige Add-ons, Erweiterungen oder Bookmarklets Skripte in Webseiten einfügen dürfen, unabhängig von deren Herkunft, und somit von den CSP-Richtlinien ausgenommen wären.

Diese Richtlinie wurde jedoch inzwischen (mit CSP 1.1) ^{[ 29 ]} wie folgt geändert. Beachten Sie die Verwendung des Wortes „kann“ anstelle der vorherigen Empfehlung „sollte“:

Hinweis: Benutzeragenten können es Benutzern ermöglichen, die Durchsetzung von Richtlinien durch Benutzereinstellungen, Bookmarklets, Erweiterungen von Drittanbietern zum Benutzeragenten und ähnliche Mechanismen zu ändern oder zu umgehen.

Die Empfehlung „sollte“ wurde von Browsernutzern verwendet, um die Einhaltung der Richtlinie zu fordern und Änderungen in gängigen Browsern (Firefox, Chrome, Safari) zu deren Unterstützung zu veranlassen. Dies war besonders umstritten, als Websites wie Twitter und GitHub begannen, strenge CSP-Richtlinien einzuführen, die die Verwendung von Bookmarklets „unbrauchbar“ machten. ^{[ 30 ]}

Die W3C- Arbeitsgruppe für Webanwendungssicherheit betrachtet solche Skripte als Teil der vom Browser implementierten Trusted Computing Base . Ein Vertreter von Cox Communications argumentierte jedoch gegenüber der Arbeitsgruppe, dass diese Ausnahme eine potenzielle Sicherheitslücke darstelle, die von bösartigen oder kompromittierten Add-ons oder Erweiterungen ausgenutzt werden könnte. ^{[ 31 ] [ 32 ]}

Seit 2015 werden vom W3C eine Reihe neuer Browser-Sicherheitsstandards vorgeschlagen, die größtenteils komplementär zu CSP sind: ^{[ 33 ]}

• Subresource Integrity ( SRI ) , um sicherzustellen, dass nur bekannte, vertrauenswürdige Ressourcendateien (typischerweise JavaScript , CSS ) von Drittanbieterservern (typischerweise CDNs )
• Gemischte Inhalte , um die beabsichtigte Browserrichtlinie für Seiten, die über HTTPS geladen werden , und Inhalte, die über unverschlüsseltes HTTP verlinkt werden, zu verdeutlichen.
• Unsichere Anfragen aktualisieren und Browsern Hinweise geben, wie sie mit älteren Links auf Seiten umgehen sollen, die auf HTTPS migriert wurden
• Credential Management , eine einheitliche JavaScript- API für den Zugriff auf Benutzeranmeldeinformationen zur Unterstützung komplexer Anmeldeverfahren,
• Referrer Policy , eine CSP-Erweiterung, die den Browser bei der Generierung der Referer -Header darauf hinweist. ^{[ 33 ]}

• Same-Origin-Richtlinie
• NoScript – Anti-XSS-Schutz und Application Boundaries Enforcer (ABE), Erweiterung für Firefox ^{[ 34 ] [ 35 ]}
• HTTP Switchboard – benutzerdefinierte CSP-Regeln, Erweiterung für Google Chrome ^{[ 36 ]} und Opera ^{[ 37 ]}
• HTTP Strict Transport Security
• HTTP Public Key Pinning

• W3C-Arbeitsentwurf zur Inhaltssicherheitsrichtlinie
• Richtlinien für sicheres Codieren im Rahmen der Content Security Policy
• Inhaltssicherheitsrichtlinie (CSP) auf MDN Web Docs