Inhaltssicherheitsrichtlinie

Inhaltssicherheitsrichtlinie (CSP) ist ein Computersicherheit Standard eingeführt, um zu verhindern Cross-Site-Scripting (Xss), ClickJacking und andere Codeinjektion Angriffe aufgrund der Ausführung böswilliger Inhalte im Vertrauen Website Kontext.[1] Es ist eine Kandidatenempfehlung der W3c Arbeitsgruppe in der Sicherheit von Webanwendungen,[2] weithin von modern unterstützt Internetbrowser.[3] CSP bietet eine Standardmethode für Website -Eigentümer, um zugelassene Ursprünge von Inhalten zu deklarieren, die Browser auf dieser Website laden dürfen - bedeckte Typen sind JavaScript, CSS, HTML -Rahmen, Webarbeiter, Schriftarten, Bilder, eingebettete Objekte wie z. Java -Applets, ActiveXAudio- und Videodateien und andere HTML5 Merkmale.

Status

Der Standard, ursprünglich als Inhaltsbeschränkungen bezeichnet, wurde 2004 von Robert Hansen vorgeschlagen.[4] zuerst implementiert in Firefox 4 und schnell von anderen Browsern abgeholt. Version 1 des Standards wurde 2012 als W3C -Kandidatenempfehlung veröffentlicht[5] und schnell mit weiteren Versionen (Stufe 2), die 2014 veröffentlicht wurden. Ab 2015 Der Entwurf von Level 3 wird entwickelt, wobei die neuen Funktionen schnell von den Webbrowsern übernommen werden.[6]

Die folgenden Headernamen werden als Teil der experimentellen CSP -Implementierungen verwendet:[3]

  • Inhaltssicherheitspolitik - Standard -Headername vom W3C -Dokument vorgeschlagen. Google Chrome Unterstützt dies als 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 (Nachtbau).[10] Chrombasis Microsoft Edge Die Unterstützung ähnelt der von Chrome. [11]
  • X-Webkit-CSP - veraltete, experimentelle Header eingeführt in Google Chrome, Safari und andere Webkit-basierte Webbrowser im Jahr 2011.[12]
  • X-In-In-In-In-Security-Policy - veraltete experimentelle Header eingeführt in Gecko 2 Basierte Browser (Firefox 4 bis Firefox 22, Thunderbird 3.3, Seamonkey 2.1).[13]

Eine Website kann mehrere CSP-Header deklarieren und auch die Durchsetzung und nur Bericht mischen. Jeder Header wird vom Browser getrennt verarbeitet.

CSP kann auch im HTML -Code mit a geliefert werden HTML Meta Tag, obwohl in diesem Fall seine Wirksamkeit begrenzt wird.[14]

Internet Explorer 10 und Internet Explorer 11 Unterstützen Sie auch CSP, aber nur die Sandbox -Richtlinie unter Verwendung des experimentellen X-In-In-In-In-Security-Policy Header.[15]

Eine Reihe von Webanwendungs ​​-Frameworks unterstützen CSP beispielsweise Angularjs[16] (nativ) und Django (Middleware).[17] Anweisungen für Rubin auf Schienen wurden gepostet von GitHub.[18] Die Unterstützung des Web Framework ist jedoch nur erforderlich, wenn der CSP -Inhalt irgendwie vom Status der Webanwendung abhängt - wie bei der Verwendung des Nonce Ursprung. Ansonsten ist der CSP ziemlich statisch und kann aus geliefert werden Webanwendungsstufen über der Anwendung zum Beispiel auf Lastenausgleicher oder Webserver.

Ab 2015 Eine Reihe neuer Browser -Sicherheitsstandards werden von W3C vorgeschlagen, die die meisten ergänzen zu CSP:[19]

  • Integrität von Subresourcen (SRI), um nur bekannte, vertrauenswürdige Ressourcendateien (normalerweise JavaScript, CSS) werden von Servern von Drittanbietern geladen (typischerweise CDNs)
  • Gemischter Inhalt, um die Richtlinien des beabsichtigten Browsers auf Seiten zu verdeutlichen, die übergeladen wurden Https und Verknüpfung von Inhalten über Klartext Http
  • Aktualisieren Sie unsichere Anfragenund deutliche Browser darüber, wie Sie mit Legacy -Links auf Seiten umgehen können, auf die migrierten Https
  • Zeugnisverwaltung, ein einheitliches JavaScript API So greifen Sie auf die Anmeldeinformationen des Benutzers zu, um komplexe Anmeldeschemata zu erleichtern.
  • Empfehlungsrichtlinie, CSP -Erweiterung, um den Browser auf die Erzeugung der zu deuten Referer Header.[19]

Bypasses

Im Dezember 2015[20] und Dezember 2016,[21] Ein paar Methoden zur Umgehung "Nonce" Die Ursprünge für die Erlaubnis wurden veröffentlicht. Im Januar 2016,[22] Eine andere Methode wurde veröffentlicht, mit der die serverweite CSP-Erlaubnis zur Nutzung alter und schutzbedürftiger Versionen von JavaScript-Bibliotheken genutzt wird, die auf demselben Server gehostet werden (häufiger Fall mit CDN-Servern). Im Mai 2017[23] Eine weitere Methode wurde veröffentlicht, um CSP mithilfe von Webanwendungs ​​-Frameworks -Code zu umgehen.

Arbeitsweise

Zuordnung zwischen HTML5- und JavaScript -Funktionen und Inhaltssicherheitsrichtlinienkontrollen

Wenn die Inhaltssicherheitspolitik Der Header ist in der Serverantwort vorhanden, ein konformer Client setzt die deklarative Zulassungsrichtlinie durch. Ein Beispielziel einer Richtlinie ist ein strengerer Ausführungsmodus für JavaScript, um bestimmte Skriptenangriffe im Cross-Standort zu verhindern. In der Praxis bedeutet dies, dass eine Reihe von Funktionen standardmäßig deaktiviert werden:

  • In der Reihe JavaScript Code[a]
    • Blöcke,[b]
    • Dom Ereignishandler als HTML -Attribute (z. ONCLICK)
    • Das JavaScript: Links
  • In der Reihe CSS Aussagen
    • Block[b]
    • Stil auf HTML -Elemente zugeschrieben
  • Dynamisch JavaScript Code -Bewertung[c]
    • eval ()
    • String -Argumente für setTimeout und setInterval Funktionen
    • neue Funktion() Konstrukteur
  • Dynamisch CSS Aussagen
    • CsStylesheet.inSertrule () Methode

Während die Verwendung von CSP in einer neuen Anwendung möglicherweise recht einfach sein kann, insbesondere mit CSP-kompatibel JavaScript Rahmen,[d] Bestehende Anwendungen erfordern möglicherweise einige Umgestaltungen - oder die Entspannung der Richtlinie. Empfohlene Codierungspraxis für CSP-kompatible Webanwendungen besteht darin, Code aus externen Quelldateien zu laden ((), analysieren JSON anstatt es zu bewerten und zu verwenden EventTarget.addeventListener () Event -Handler festlegen.[24]

Anmerkungen

  1. ^ Dieses Verhalten kann weltweit von einem Spezifischen deaktiviert werden "Unsicherer Inline" Aussage
  2. ^ a b Vertrauenswürdige Inline und Blöcke können einzeln in der CSP verwendet werden Nonce oder Hash Aussagen.
  3. ^ Dieses Verhalten kann weltweit von einem Spezifischen deaktiviert werden "unsicher-eval" Aussage
  4. ^ Zum Beispiel, Angularjs erfordert, dass nur ein Initialisierungsflag in den CSP-kompatiblen Modus umgestellt wird-

Berichterstattung

Jedes Mal, wenn eine angeforderte Ressource oder eine Skriptausführung gegen die Richtlinie verstößt, wird der Browser a abfeuern POST Anfrage an den in angegebenen Wert in Report-uri[25] oder Bericht an [26] enthält Details des Verstoßes.

CSP -Berichte sind Standard JSON Strukturen und können entweder von der Anwendung erfasst werden API[27] oder öffentliche CSP -Berichtsempfänger.

Im Jahr 2018 zeigten Sicherheitsforscher, wie man falsch positive Berichte an den festgelegten Empfänger sendet Report-uri . Dies ermöglicht es potenziellen Angreifern, diese Alarme willkürlich auszulösen, und kann sie bei einem realen Angriff weniger nützlich machen.[28] Dieses Verhalten ist beabsichtigt und kann nicht behoben werden, da der Browser (Client) die Berichte sendet.

Browser-Add-Ons und Extensionsbefreiung

Gemäß dem ursprünglichen CSP -Verarbeitungsmodell (1.0) (2012–2013),,[29] CSP sollte den Betrieb von Browser-Add-Ons oder vom Benutzer installierten Erweiterungen nicht beeinträchtigen. Diese Funktion von CSP hätte jegliches Add-On, Erweiterung oder effektiv zugelassen Lesezeichen Skript in Websites injizieren, unabhängig vom Ursprung dieses Skripts, und somit von CSP -Richtlinien befreit werden.

Diese Richtlinie wurde jedoch inzwischen geändert (ab CSP 1.1[30]) mit dem folgenden Wortlaut. Beachten Sie die Verwendung des Wortes "Mai" anstelle des vorherigen Absolutes "sollte (nicht)" Formulierung:

Hinweis: Benutzeragenten kann Ermöglichen Sie den Benutzern die Durchsetzung von Richtlinien durch Benutzerpräferenzen, Lesezeichen, Drittanbieter und andere solche Mechanismen.

Der absolute "sollte" -Sturm wurde von Browserbenutzern verwendet, um die Einhaltung der Richtlinie zu beantragen/zu fordern und Änderungen in beliebten Browsern (Firefox, Chrome, Safari) zu installieren, um sie zu unterstützen. Dies war besonders umstritten, als Websites wie Twitter und Github starke CSP -Richtlinien verwendeten, die die Verwendung von Lesezeichen „brachen“.[31]

Das W3c Die Arbeitsgruppe für Webanwendungen für Sicherheit betrachtet ein solches Skript als Teil der Vertrauenswürdige Computerbasis durch den Browser implementiert; Es wurde jedoch der Arbeitsgruppe von einem Vertreter von von einem Vertreter von argumentiert Cox -Kommunikation Dass diese Ausnahme ein potenzielles Sicherheitsloch ist, das durch böswillige oder kompromittierte Add-Ons oder Erweiterungen ausgenutzt werden kann.[32][33]

Siehe auch

Verweise

  1. ^ Sid Stamm (2009-03-11). "Sicherheit/CSP/Spec - Mozillawiki". Wiki.mozilla.org. Abgerufen 2011-06-29. Die Inhaltssicherheitsrichtlinie soll Webdesignern oder Serveradministratoren helfen, wie Inhalte auf ihren Websites interagieren. Es hilft, Arten von Angriffen wie XSS und Dateninjektion zu mildern und zu erkennen.
  2. ^ "Zustand des Entwurfs". 2016-09-13. Abgerufen 2016-10-05.
  3. ^ a b "Kann ich Inhaltssicherheitsrichtlinien verwenden?". Fyrd. Abgerufen 22. Februar, 2013.
  4. ^ Robert Hansen (2009-06-01). "Mozillas Inhaltssicherheitsrichtlinie". Archiviert von das Original am 18. März 2015. Abgerufen 2011-06-29. Inhaltsbeschränkungen - Eine Möglichkeit für Websites, dem Browser zu sagen, dass er seine Sicherheit auf Seiten erhöhen soll, auf denen die Website weiß, dass der Inhalt benutzergerechnet ist und daher möglicherweise gefährlich ist.
  5. ^ "Inhaltssicherheitsrichtlinie 1.0". W3c. Abgerufen 2015-11-13.
  6. ^ "Inhaltssicherheitsrichtlinie Level 3". W3c. Abgerufen 2015-11-13.
  7. ^ "Chrome 25 Beta: Inhaltssicherheitsrichtlinie und Shadow Dom". Google. 14. Januar 2013. Abgerufen 22. Februar, 2013.
  8. ^ "Inhaltssicherheitspolitik 1.0 landet in Firefox Aurora". Mozilla Foundation. 29. Mai 2013. Abgerufen 16. Juni, 2013.
  9. ^ "RapidRelease/Kalender". Mozilla Foundation. 29. Mai 2013. Abgerufen 16. Juni, 2013.
  10. ^ "Bug 96765-Implementieren Sie den" Header "" Inhaltssicherheitspolitik ". Webkit. 31. Oktober 2012. Abgerufen 7. August, 2015.
  11. ^ "Inhaltssicherheitsrichtlinie (CSP)". Microsoft. Abgerufen 6. Februar, 2020.
  12. ^ "Neue Chrom -Sicherheitsfunktionen, Juni 2011". Google. 14. Juni 2011. Abgerufen 22. Februar, 2013.
  13. ^ "Einführung der Inhaltssicherheitsrichtlinie". Mozilla Foundation. Abgerufen 22. Februar, 2013.
  14. ^ "HTML -Meta -Element". Inhaltssicherheitsrichtlinie Level 2. W3c. Abgerufen 2015-11-14.
  15. ^ "Verteidigung in der Tiefe: Mash-ups mit HTML5-Sandbox einsperren". Windows Internet Explorer Engineering Team. Abgerufen 13. April, 2014.
  16. ^ "NGCSP -Richtlinie". Angularjs. Abgerufen 27. Oktober, 2020.
  17. ^ "Django-Sicherheit".
  18. ^ "Inhaltssicherheitsrichtlinie". Github.
  19. ^ a b "Arbeitsgruppe für Webanwendungssicherheit". Abgerufen 2015-11-13.
  20. ^ "CSP 2015". XSS Jigsaw. Abgerufen 12. Dezember, 2015.
  21. ^ Lekies, Sebastian. "Sammlung von CSP -Umgehungsstern". Abgerufen 2017-06-05.
  22. ^ "Eine missbräuchliche Beziehung zu AngularJs". Abgerufen 5. Januar, 2016.
  23. ^ Owasp (2017-05-25), AppSec EU 2017 Vertrauen Sie nicht dem DOM: Umgang mit XSS -Minderungen über Skript -Geräte von Sebastian Lekies, abgerufen 2017-06-05
  24. ^ West, Mike (15. Juni 2012). "Eine Einführung in die Inhaltssicherheitsrichtlinie". HTML5 Rocks. Abgerufen 22. Februar, 2013.
  25. ^ "Inhaltssicherheitsrichtlinie Level 3". www.w3.org. Abgerufen 2021-01-12.
  26. ^ "CSP: Report -to - Http | Mdn". Entwickler.mozilla.org. Abgerufen 2021-01-25.
  27. ^ Zum Beispiel in Django Ein CSP -Empfänger ist in erhältlich Django-Sicherheit Modul.
  28. ^ "Das blaue Team flackern - Wenn Sie sie verwirren, verlieren Sie sie". SecJuice. 2018-11-04. Abgerufen 2019-12-27.
  29. ^ "CSP -Verarbeitungsmodell". 2012-11-15. Abgerufen 2013-10-06.
  30. ^ "CSP 1.1: Nicht normative Sprache für Erweiterungen hinzufügen". GitHub W3C WebAppSec. Github. 27. Februar 2014. Abgerufen 14 Sep 2016.
  31. ^ "Bug 866522 - von CSP betroffene Lesezeichen". Bugzilla. Mozilla. 28. April 2013. Abgerufen 14 Sep 2016.
  32. ^ "Unterverting CSP-Richtlinien für Browser-Add-Ons (Erweiterungen)". 2013-09-25. Abgerufen 2013-10-06.
  33. ^ "Betreff: [CSP] Anfrage, ein Lesezeichen/Erweiterungssatz in Csp1.1 zu ändern". 2014-08-03. Abgerufen 2015-10-08.
  34. ^ "NoScript Security Suite Addon für Firefox". addons.mozilla.org. Abgerufen 11. Juni 2017.
  35. ^ "Die NoScript Firefox -Erweiterung - offizielle Site". noscript.net. Abgerufen 11. Juni 2017.
  36. ^ "HTTP -Schalttafel für Chrome". Chrome.google.com. Archiviert von das Original Am 2014-08-17.
  37. ^ "HTTP -Schalttafel für Opera". addons.opera.com. Abgerufen 11. Juni 2017.

Externe Links