| OLD | NEW |
|---|
| (Empty) | |
| 1 <h1 class="page_title">Content Security Policy (CSP)</h1> |
| 2 <div id="pageData-showTOC" class="pageData">true</div> |
| 3 <p> |
| 4 In order to mitigate a large class of potental cross-site scripting issues, |
| 5 Chrome's extension system has incorporated the general concept of |
| 6 <a href="http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specif
ication.dev.html"> |
| 7 <strong>Content Security Policy (CSP)</strong> |
| 8 </a>. This introduces some fairly strict policies that will make extensions |
| 9 more secure by default, and provides you with the ability to create and |
| 10 enforce rules governing the types of content that can be loaded and executed |
| 11 by your extensions and applications. |
| 12 </p> |
| 13 <p> |
| 14 In general, CSP works as a black/whitelisting mechanism for resources loaded |
| 15 or executed by your extensions. Defining a reasonable policy for your |
| 16 extension enables you to carefully consider the resources that your extension |
| 17 requires, and to ask the browser to ensure that those are the only resources |
| 18 your extension has access to. These policies provide security over and above |
| 19 the <a href="manifest.html#permissions">host permissions</a> your extension |
| 20 requests; they're an additional layer of protection, not a replacement. |
| 21 </p> |
| 22 <p> |
| 23 On the web, such a policy is defined via an HTTP header or <code>meta</code> |
| 24 element. Inside Chrome's extension system, neither is an appropriate |
| 25 mechanism. Instead, an extension's policy is defined via the extension's |
| 26 <a href="manifest.html"><code>manifest.json</code></a> file as follows: |
| 27 </p> |
| 28 <pre>{ |
| 29 ..., |
| 30 "content_security_policy": "[POLICY STRING GOES HERE]" |
| 31 ... |
| 32 }</pre> |
| 33 <p class="note"> |
| 34 For full details regarding CSP's syntax, please take a look at |
| 35 <a href="http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specif
ication.dev.html#syntax"> |
| 36 the Content Security Policy specification |
| 37 </a>. |
| 38 </p> |
| 39 <h2>Default Policy Restrictions</h2> |
| 40 <p> |
| 41 Packages that do not define a <a href="manifestVersion.html"> |
| 42 <code>manifest_version</code> |
| 43 </a> have no default content security policy. Those that select |
| 44 <code>manifest_version</code></a> 2, have a default content security policy |
| 45 of: |
| 46 </p> |
| 47 <pre>script-src 'self'; object-src 'self'</pre> |
| 48 <p> |
| 49 This policy adds security by limiting extensions and applications in two ways: |
| 50 </p> |
| 51 <h3>Inline JavaScript will not be executed</h3> |
| 52 <p> |
| 53 Inline JavaScript, as well as dangerous string-to-JavaScript methods like |
| 54 <code>eval</code>, will not be executed. This restriction bans both inline |
| 55 <code><script></code> blocks <strong>and</strong> inline event handlers |
| 56 (e.g. <code><button onclick="..."></code>). |
| 57 </p> |
| 58 <p> |
| 59 The first restriction wipes out a huge class of cross-site scripting attacks |
| 60 by making it impossible for you to accidentally execute script provided by a |
| 61 malicious third-party. It does, however, require you to write your code with a |
| 62 clean separation between content and behavior (which you should of course do |
| 63 anyway, right?). An example might make this clearer. You might try to write a |
| 64 <a href="browserAction.html#popups">Browser Action's popup</a> as a single |
| 65 <code>popup.html</code> containing: |
| 66 </p> |
| 67 <pre><!doctype html> |
| 68 <html> |
| 69 <head> |
| 70 <title>My Awesome Popup!</title> |
| 71 <script> |
| 72 function awesome() { |
| 73 // do something awesome! |
| 74 } |
| 75 function totallyAwesome() { |
| 76 // do something TOTALLY awesome! |
| 77 } |
| 78 function clickHandler(element) { |
| 79 setTimeout(<strong>"awesome(); totallyAwesome()"</strong>, 1000); |
| 80 } |
| 81 </script> |
| 82 </head> |
| 83 <body> |
| 84 <button <strong>onclick="clickHandler(this)"</strong>> |
| 85 Click for awesomeness! |
| 86 </button> |
| 87 </body> |
| 88 </html></pre> |
| 89 <p> |
| 90 Three things will need to change in order to make this work the way you expect |
| 91 it to: |
| 92 </p> |
| 93 <ul> |
| 94 <li> |
| 95 The <code>clickHandler</code> definition needs to move into an external |
| 96 JavaScript file (<code>popup.js</code> would be a good target). |
| 97 </li> |
| 98 <li> |
| 99 The inline event handler definition must be rewritten in terms of |
| 100 <code>addEventListener</code> and extracted into <code>popup.js</code>. |
| 101 </li> |
| 102 <li> |
| 103 The <code>setTimeout</code> call will need to be rewritten to avoid |
| 104 converting the string <code>"awesome(); totallyAwesome()"</code> into |
| 105 JavaScript for execution. |
| 106 </li> |
| 107 </ul> |
| 108 <p> |
| 109 Those changes might look something like the following: |
| 110 </p> |
| 111 <pre>popup.js: |
| 112 ========= |
| 113 function awesome() { |
| 114 // Do something awesome! |
| 115 } |
| 116 function totallyAwesome() { |
| 117 // do something TOTALLY awesome! |
| 118 } |
| 119 <strong> |
| 120 function awesomeTask() { |
| 121 awesome(); |
| 122 totallyAwesome(); |
| 123 } |
| 124 </strong> |
| 125 function clickHandler(e) { |
| 126 setTimeout(<strong>awesomeTask</strong>, 1000); |
| 127 } |
| 128 // Add event listeners once the DOM has fully loaded by listening for the |
| 129 // `DOMContentLoaded` event on the document, and adding your listeners to |
| 130 // specific elements when it triggers. |
| 131 document.addEventListener('DOMContentLoaded', function () { |
| 132 document.querySelector('button').addEventListener('click', clickHandler); |
| 133 }); |
| 134 popup.html: |
| 135 =========== |
| 136 <!doctype html> |
| 137 <html> |
| 138 <head> |
| 139 <title>My Awesome Popup!</title> |
| 140 <script <strong>src="popup.js"</strong>></script> |
| 141 </head> |
| 142 <body> |
| 143 <button>Click for awesomeness!</button> |
| 144 </body> |
| 145 </html></pre> |
| 146 <p> |
| 147 <h3>Only local script and and object resources are loaded</h3> |
| 148 <p> |
| 149 Script and object resources can only be loaded from the extension's |
| 150 package, not from the web at large. This ensures that your extension only |
| 151 executes the code you've specifically approved, preventing an active network |
| 152 attacker from maliciously redirecting your request for a resource. |
| 153 </p> |
| 154 <p> |
| 155 Instead of writing code that depends on jQuery (or any other library) loading |
| 156 from an external CDN, consider including the specific version of jQuery in |
| 157 your extension package. That is, instead of: |
| 158 </p> |
| 159 <pre><!doctype html> |
| 160 <html> |
| 161 <head> |
| 162 <title>My Awesome Popup!</title> |
| 163 <script src="<strong>http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jq
uery.min.js</strong>"></script> |
| 164 </head> |
| 165 <body> |
| 166 <button>Click for awesomeness!</button> |
| 167 </body> |
| 168 </html></pre> |
| 169 <p> |
| 170 Download the file, include it in your package, and write: |
| 171 <p> |
| 172 <pre><!doctype html> |
| 173 <html> |
| 174 <head> |
| 175 <title>My Awesome Popup!</title> |
| 176 <script src="<strong>jquery.min.js</strong>"></script> |
| 177 </head> |
| 178 <body> |
| 179 <button>Click for awesomeness!</button> |
| 180 </body> |
| 181 </html></pre> |
| 182 <h2>Relaxing the default policy</h2> |
| 183 <p> |
| 184 There is no mechanism for relaxing the restriction against executing inline |
| 185 JavaScript. In particular, setting a script policy that includes |
| 186 <code>unsafe-inline</code> will have no effect. This is intentional. |
| 187 </p> |
| 188 <p> |
| 189 If, on the other hand, you have a need for some external JavaScript or object |
| 190 resources, you can relax the policy to a limited extent by whitelisting |
| 191 secure origins from which scripts should be accepted. We want to ensure that |
| 192 executable resources loaded with an extension's elevated permissions are |
| 193 exactly the resources you expect, and haven't been replaced by an active |
| 194 network attacker. As <a |
| 195 href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">man-in-the-middle |
| 196 attacks</a> are both trivial and undetectable over HTTP, those origins will |
| 197 not be accepted. Currently, we allow whitelisting origins with the following |
| 198 schemes: <code>HTTPS</code>, <code>chrome-extension</code>, and |
| 199 <code>chrome-extension-resource</code>. |
| 200 </p> |
| 201 <p> |
| 202 A relaxed policy definition which allows script resources to be loaded from |
| 203 <code>example.com</code> over HTTPS might look like: |
| 204 </p> |
| 205 <pre>{ |
| 206 ..., |
| 207 "content_security_policy": "script-src 'self' https://example.com; object-src
'self'", |
| 208 ... |
| 209 }</pre> |
| 210 <p class="note"> |
| 211 Note that both <code>script-src</code> and <code>object-src</code> are defined |
| 212 by the policy. Chrome will not accept a policy that doesn't limit each of |
| 213 these values to (at least) <code>'self'</code>. |
| 214 </p> |
| 215 <p> |
| 216 Making use of Google Analytics is the canonical example for this sort of |
| 217 policy definition. It's common enough that we've provided an Analytics |
| 218 boilerplate of sorts in the <a href="samples.html#analytics">Event Tracking |
| 219 with Google Analytics</a> sample extension, and a |
| 220 <a href="tut_analytics.html">brief tutorial</a> that goes into more detail. |
| 221 </p> |
| 222 <h2>Tightening the default policy</h2> |
| 223 <p> |
| 224 You may, of course, tighten this policy to whatever extent your extension |
| 225 allows in order to increase security at the expense of convenience. To specify |
| 226 that your extension can only load resources of <em>any</em> type (images, etc) |
| 227 from its own package, for example, a policy of <code>default-src 'self'</code> |
| 228 would be appropriate. The <a href="samples.html#mappy">Mappy</a> sample |
| 229 extension is a good example of an extension that's been locked down above and |
| 230 beyond the defaults. |
| 231 </p> |
| OLD | NEW |
|---|
Chromium Code Reviews
Issue 10832042:
Extensions Docs Server: Doc conversion script (Closed)
Base URL: svn://svn.chromium.org/chrome/trunk/src