Heim  >  Artikel  >  Web-Frontend  >  Content Security Policy (CSP) in HTML5

Content Security Policy (CSP) in HTML5

一个新手
一个新手Original
2017-10-07 11:40:002597Durchsuche

Vorwort:

Cordova不支持内联事件,所以点击事件必须提取到js里面.
以下是从官网摘抄下来,希望对您有所帮助

Um eine große Anzahl potenzieller Cross-Site-Scripting-Probleme zu lindern, hat das Chrome-Erweiterungssystem das allgemeine Konzept der Content Security Policy (CSP) integriert. Dadurch werden einige ziemlich strenge Richtlinien eingeführt, die Erweiterungen standardmäßig sicherer machen und Ihnen die Möglichkeit geben, Regeln zu erstellen und durchzusetzen, die die Arten von Inhalten regeln, die von Erweiterungen und Anwendungen geladen und ausgeführt werden können.

Im Allgemeinen fungiert CSP als Hacking-/Whitelisting-Mechanismus zum Erweitern von Ressourcen, die ein Programm lädt oder ausführt. Indem Sie eine sinnvolle Richtlinie für Ihre Erweiterung definieren, können Sie die von Ihrer Erweiterung benötigten Ressourcen sorgfältig abwägen und den Browser bitten, sicherzustellen, dass Ihre Erweiterung nur auf diese Ressourcen zugreifen kann. Diese Richtlinien bieten Sicherheit, die über die von Ihrer Erweiterung angeforderten Hostberechtigungen hinausgeht. Sie stellen eine zusätzliche Schutzebene dar und stellen keinen Ersatz dar.

Im Web werden solche Richtlinien durch HTTP-Header oder -Elemente definiert. Auch im Erweiterungssystem von Chrome gibt es keinen geeigneten Mechanismus. Stattdessen wird die Richtlinie einer Erweiterung über die Datei manifest.json der Erweiterung definiert, die wie folgt aussieht:

{ 
   … 
   “content_security_policy”:“[POLICY STRING GOES HERE]” 
   …
}

Ausführliche Informationen zur CSP-Syntax finden Sie in der Spezifikation der Content Security Policy und im Abschnitt „Content on HTML5Rocks“. Artikel „Einführung in die Sicherheitspolitik“.

Standardrichtlinieneinschränkung

Manifest_version-Paket nicht definiert hat keine Standardrichtlinie für die Inhaltssicherheit. Diejenigen, die manifest_version 2 wählen, haben die Standard-Inhaltssicherheitsrichtlinie:

script-src'self'; object-src'self'

Diese Richtlinie erhöht die Sicherheit, indem sie Erweiterungen und Anwendungen auf drei Arten einschränkt Eigenschaften:

(1) Auswertung und zugehörige Funktionen sind deaktiviert

Der folgende Code funktioniert nicht:

alert(eval("foo.bar .baz"));

window.setTimeout(“alert(’hi’)”,10); 
 window.setInterval(“alert(’hi’)”,10); 
 new Function(“return foo.bar.baz”);

Die Auswertung einer JavaScript-Zeichenfolge wie dieser ist ein häufiger XSS-Angriffsvektor. Stattdessen sollten Sie Code wie diesen schreiben:

alert(foo && foo.bar && foo.bar.baz); 
window.setTimeout(function(){alert(’hi’);},10); 
window.setInterval(function(){alert(’hi’);},10); 
function(){return foo && foo.bar && foo.bar.baz};

(2) Inline-JavaScript wird nicht ausgeführt

Inline-JavaScript wird nicht ausgeführt. Diese Einschränkung verbietet Inline-Blöcke und Inline-Ereignishandler-Prozeduren (z. B. ).

Die erste Einschränkung eliminiert eine große Anzahl von Cross-Site-Scripting-Angriffen, indem sie verhindert, dass Sie versehentlich Skripte ausführen, die von böswilligen Dritten bereitgestellt werden. Aber es erfordert eine klare Trennung zwischen dem, was Ihr Code schreibt, und dem, was er tut (was Sie auf jeden Fall tun sollten), oder? Ein Beispiel könnte dies verdeutlichen. Sie könnten versuchen, ein Browser-Aktions-Popup als einzelnes popup.html zu schreiben, das Folgendes enthält:

Klicken Sie hier, um es zu sehen!
<!doctype html> 
      My Awesome Popup! 
       function awesome(){ 
         //做某事真棒! 
       }
   function totalAwesome(){
     //做某事真棒!
   }
  函数clickHandler(element){
     setTimeout( “awesome();getherAwesome()” ,1000);
   }
   function main(){
     //初始化工作在这里。
   }
 </ SCRIPT>


Standardrichtlinie lockern

(1) Inline-Skripte

Bis Chrome 45 gab es keine Lockerung der Einschränkungen für die Ausführung von Inline-JavaScript-Mechanismen . Insbesondere das Festlegen einer Skriptrichtlinie, die „unsafe-inline“ enthält, hat keine Auswirkung.

Ab Chrome 46 ist es möglich, Inline-Skripte auf die Whitelist zu setzen, indem der Base64-codierte Hash des Quellcodes in der Richtlinie angegeben wird. Dem Hash muss der verwendete Hashing-Algorithmus (sha256, sha384 oder sha512) vorangestellt werden.

über Beispiele

Das obige ist der detaillierte Inhalt vonContent Security Policy (CSP) in HTML5. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn