Content Security Policy (CSP) in HTML5

Foreword:

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

To alleviate a large number of potential cross-site scripting issues, Chrome's extension system has incorporated the general concept of Content Security Policy (CSP). This introduces some fairly strict policies that will make extensions more secure by default and give you the ability to create and enforce rules that govern the types of content that can be loaded and executed by extensions and applications.

Generally speaking, CSP acts as a hacking/whitelisting mechanism for resources that extensions load or execute. By defining a sensible policy for your extension, you can carefully consider the resources your extension requires and ask the browser to ensure that these are the only ones your extension can access. These policies provide security beyond the host permissions requested by your extension; they are an additional layer of protection, not a replacement.

On the web, such policies are defined through HTTP headers or elements. Neither is a suitable mechanism in Chrome's extension system. Instead, an extension's policy is defined via the extension's manifest.json file, as shown below:

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

For complete details on CSP syntax, see the Content Security Policy specification and the "Content Security Policy" section on HTML5Rocks Introduction" article.

Default policy restrictions

The manifest_version package is not defined and does not have a default content security policy. Those that select manifest_version 2, have the default content security policy:

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

This policy increases security by restricting extensions and applications in three ways Performance:

(1) Evaluation and related functions are disabled

The following code does not work:

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

window.setTimeout（“alert（’hi’）”，10）; 
 window.setInterval（“alert（’hi’）”，10）; 
 new Function（“return foo.bar.baz”）;

Evaluating such a JavaScript string is a common XSS attack vector. Instead, you should write the following code:

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 will not be executed

Inline JavaScript will not be executed. This restriction prohibits inline blocks and inline event handlers programs (such as ).

The first restriction eliminates a large number of cross-site scripting attacks by preventing you from accidentally executing scripts provided by malicious third parties. However, it requires a clean separation between what your code writes and how it behaves (which you should certainly do) right? An example might make this clearer. You might try writing a browser-action popup as a single popup.html containing:

<！doctype html> 
      My Awesome Popup！ 
       function awesome（）{ 
         //做某事真棒！ 
       }
   function totalAwesome（）{
     //做某事真棒！
   }
  函数clickHandler（element）{
     setTimeout（ “awesome（）;getherAwesome（）” ，1000）;
   }
   function main（）{
     //初始化工作在这里。
   }
 </ SCRIPT>

Click for awesomeness!

Relax the default policy

(1) Inline script

Until Chrome 45, there was no relaxation of restrictions on executing inline JavaScript mechanism. In particular, setting a script policy containing 'unsafe-inline' will have no effect.

Starting with Chrome 46, it is possible to whitelist inline scripts by specifying the base64-encoded hash of the source code in the policy. The hash must be prefixed by the hashing algorithm used (sha256, sha384 or sha512).

about examples

The above is the detailed content of Content Security Policy (CSP) in HTML5. For more information, please follow other related articles on the PHP Chinese website!