Closed Bug 735287 Opened 12 years ago Closed 8 years ago

Implement Content Security Policy (CSP) for Bedrock

Categories

(www.mozilla.org :: Bedrock, defect)

Product:
www.mozilla.org
Component:
Bedrock
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: wenzel, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: sec-moderate, Whiteboard: [infrasec:bestpractice][ws:moderate]) 

Please enable django-csp on bedrock.

The biggest requirement will be removing inline script blocks, though I hope we don't have (m)any of those in bedrock anyway.

For an app that uses this successfully, check out Firefox Flicks.
Whiteboard: [infrasec:bestpractice][ws:moderate]
Btw, this will break webtrends because that's all inline. But that's fixable, AMO and SUMO and many other projects do not use webtrends inline.
Component: www.mozilla.org/firefox → www.mozilla.org
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
Component: General → Bedrock
Blocks: mozorg-opt
Optimizely is also a blocker to full CSP on bedrock even that it has eval() on select www.mozilla.org pages.

Here's the optimizely JS that is being used to run content and product tests on www.mozilla.org/firefox/new/: https://cdn.optimizely.com/js/246059135.js
Can we enable CSP on www.mozilla.org with unsafe-inline and unsafe-eval for now as that is still better than no CSP per https://bugzilla.mozilla.org/show_bug.cgi?id=1053845#c34 ?

We can continue to put pressure on our vendors to provide a service that allows for full CSP functionality. This would be a win-win for everyone if they could.
Flags: needinfo?(pmac)
Yup. I've got this on my list. It's also possible we could enhance django-csp to support script-nonce and/or script-hash to allow for these known instances of inline script without having to allow all inline scripts. I'm not sure yet of the browser compatibility for those new directives however. Something to look more deeply into though.
Flags: needinfo?(pmac)
I'm fine with django-csp, or any way that we want to get it done.  Poking around on bedrock, there doesn't seem to be that many remaining inline scripts. 

> www.mozilla.org/:150 Refused to execute inline script because it violates the following Content Security Policy directive: "default-src https:". Either the 'unsafe-inline' keyword, a hash ('sha256-jKMjk1/lyDbYcB03K5hNX44YAl6lR7iNW7Zzgq3Fi54='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.

A <script> in <head> related to window.datalayer.

> www.mozilla.org/:157 Refused to execute inline script because it violates the following Content Security Policy directive: "default-src https:". Either the 'unsafe-inline' keyword, a hash ('sha256-iOs4LtOIw77sveR31kfO8srMW2ZbUKPD9a9MKW4FJOo='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.

A <script> in <head> related to do-not-track.

Both of those should (hopefully) be relatively easy to move to external sources. They move around in the source, but it seems to be mainly those two includes everywhere.  There are also some unsafe evals in some of the optimizely bits, and those probably would need to get killed as well.  There are also a lot of problems with inline styles, but I am somewhat less concerned with those. They should also be fixed, but I understand that the effort is higher and the risk is somewhat lower, particularly if other CSP measures are implemented.

So we could start with something relatively open like this:

> Content-Security-Policy: default-src https:; img-src data: https:; style-src https: 'unsafe-inline'

Kill inline stylesheets and move to this:

> Content-Security-Policy: default-src https:; img-src data: https:; style-src https:

And then hopefully move to something a good deal more locked down.  This seemed to work in my brief testing (aside from the inline/eval stuff), but will probably require a good deal more testing:

> Content-Security-Policy: default-src none; connect-src https://*.tiles.mapbox.com; font-src 'self'; img-src data: 'self' https://*.tiles.mapbox.com; script-src 'self' https://geo.mozilla.org https://*.optimizely.com; style-src 'self'

The first two entries disable inline javascript, but will still allow XSS's to load if they can inject <script> tags.  The final one will prevent that as well, and is really what we're hoping to reach to cut off almost all XSS vectors in bedrock.
Summary: [bedrock] Enable django-csp to enforce content security policies → Implement Content Security Policy (CSP) for Bedrock
Depends on: 1247652
We do now have a CSP policy in production. It needs more work, but it's a good start I think. I'll file follow-up bugs for further changes.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.