Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(165)

Side by Side Diff: chrome/common/extensions/docs/server2/templates/articles/contentSecurityPolicy.html

Issue 10832042: Extensions Docs Server: Doc conversion script (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src
Patch Set: script/build.py fixes Created 8 years, 4 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch | Annotate | Revision Log
OLDNEW
(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>&lt;script&gt;</code> blocks <strong>and</strong> inline event handlers
55 (e.g. <code>&lt;button onclick="..."&gt;</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>&lt;!doctype html&gt;
67 &lt;html&gt;
68 &lt;head&gt;
69 &lt;title&gt;My Awesome Popup!&lt;/title&gt;
70 &lt;script&gt;
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 &lt;/script&gt;
81 &lt;/head&gt;
82 &lt;body&gt;
83 &lt;button <strong>onclick="clickHandler(this)"</strong>&gt;
84 Click for awesomeness!
85 &lt;/button&gt;
86 &lt;/body&gt;
87 &lt;/html&gt;</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 &lt;!doctype html&gt;
136 &lt;html&gt;
137 &lt;head&gt;
138 &lt;title&gt;My Awesome Popup!&lt;/title&gt;
139 &lt;script <strong>src="popup.js"</strong>&gt;&lt;/script&gt;
140 &lt;/head&gt;
141 &lt;body&gt;
142 &lt;button&gt;Click for awesomeness!&lt;/button&gt;
143 &lt;/body&gt;
144 &lt;/html&gt;</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>&lt;!doctype html&gt;
159 &lt;html&gt;
160 &lt;head&gt;
161 &lt;title&gt;My Awesome Popup!&lt;/title&gt;
162 &lt;script src="<strong>http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jq uery.min.js</strong>"&gt;&lt;/script&gt;
163 &lt;/head&gt;
164 &lt;body&gt;
165 &lt;button&gt;Click for awesomeness!&lt;/button&gt;
166 &lt;/body&gt;
167 &lt;/html&gt;</pre>
168 <p>
169 Download the file, include it in your package, and write:
170 <p>
171 <pre>&lt;!doctype html&gt;
172 &lt;html&gt;
173 &lt;head&gt;
174 &lt;title&gt;My Awesome Popup!&lt;/title&gt;
175 &lt;script src="<strong>jquery.min.js</strong>"&gt;&lt;/script&gt;
176 &lt;/head&gt;
177 &lt;body&gt;
178 &lt;button&gt;Click for awesomeness!&lt;/button&gt;
179 &lt;/body&gt;
180 &lt;/html&gt;</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>
OLDNEW

Powered by Google App Engine
This is Rietveld 408576698