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