Content-Security-Policy coming to a WebUI near you
Adam Barth
Content-Security-Policy helps you mitigate cross-site scripting by
attaching a security policy to a web page. For example, you can
create a whitelist for which script URLs can run in your page,
preventing an attacker from injecting his or her malicious scripts.
We're dogfooding this feature by using it internally for the
HTML-based UI in Chrome. Eventually, we want to add a
Content-Security-Policy by default to all content in the browser with
a "chrome" URL. Applying a policy to a page usually requires a couple
of changes:
1) All inline scripts need to be moved out-of-line. The browser can't
tell whether you wrote an inline script or whether the script was
injected by an attacker. By moving script out-of-line (i.e., into a
<script src="...">), the browser can check the URL of the script
against the whitelist.
2) Pages cannot use APIs that turn strings into scripts, such as eval,
JavaScript URLs, or setTimeout with a string argument. (You can still
use setTimeout with a function argument because that doesn't turn any
strings into code).
So far, Tom Sepez and I have added Content-Security-Policies to the
Bookmark Manager and the Preferences UI. Tom has patches for the
History and the Downloads UI in flight. We'll be working through the
rest of the HTML-based UI in due course. Once we've gone through all
the UI we can find, we're going to start applying a policy by default,
which will probably cause some amount breakage for page we've missed.
(I'll send out another email before we flip the default.)
If you own any HTML-based UI that you'd like to make more secure,
please email Tom and myself. We can point you in the right direction.
Thanks!
Adam
Ojan Vafai
If you don't work on HTML-based UI, you should feel free to ignore this message.
Content-Security-Policy helps you mitigate cross-site scripting by
attaching a security policy to a web page. For example, you can
create a whitelist for which script URLs can run in your page,
preventing an attacker from injecting his or her malicious scripts.
We're dogfooding this feature by using it internally for the
HTML-based UI in Chrome. Eventually, we want to add a
Content-Security-Policy by default to all content in the browser with
a "chrome" URL. Applying a policy to a page usually requires a couple
of changes:
1) All inline scripts need to be moved out-of-line. The browser can't
tell whether you wrote an inline script or whether the script was
injected by an attacker. By moving script out-of-line (i.e., into a
<script src="...">), the browser can check the URL of the script
against the whitelist.
2) Pages cannot use APIs that turn strings into scripts, such as eval,
JavaScript URLs, or setTimeout with a string argument. (You can still
use setTimeout with a function argument because that doesn't turn any
strings into code).
So far, Tom Sepez and I have added Content-Security-Policies to the
Bookmark Manager and the Preferences UI. Tom has patches for the
History and the Downloads UI in flight. We'll be working through the
rest of the HTML-based UI in due course. Once we've gone through all
the UI we can find, we're going to start applying a policy by default,
which will probably cause some amount breakage for page we've missed.
(I'll send out another email before we flip the default.)
If you own any HTML-based UI that you'd like to make more secure,
please email Tom and myself. We can point you in the right direction.
Thanks!
Adam
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
