Define a Content Security Policy (CSP) for treeherder.mozilla.org
Categories
(Tree Management :: Treeherder: Infrastructure, defect, P1)
Tracking
(Not tracked)
People
(Reporter: emorley, Assigned: emorley)
References
(Blocks 2 open bugs)
Details
Attachments
(3 files)
Assignee | ||
Comment 1•8 years ago
|
||
Assignee | ||
Comment 2•8 years ago
|
||
Assignee | ||
Comment 3•8 years ago
|
||
Assignee | ||
Comment 4•8 years ago
|
||
Assignee | ||
Comment 5•8 years ago
|
||
Comment 6•8 years ago
|
||
Assignee | ||
Comment 7•8 years ago
|
||
Comment 8•8 years ago
|
||
Assignee | ||
Comment 9•8 years ago
|
||
Assignee | ||
Comment 10•7 years ago
|
||
Assignee | ||
Comment 11•6 years ago
|
||
Assignee | ||
Comment 12•6 years ago
|
||
I have a WIP for this locally. I think we should proceed with this even though we're waiting on bug 1507903, since we can always use unsafe-inline for CSS for now on the main job view and remove it later once the bug is fixed.
Comment 13•6 years ago
|
||
Assignee | ||
Comment 14•6 years ago
|
||
The first part of this has landed, which adds a report-only CSP header and an API endpoint for collecting violation reports:
https://github.com/mozilla/treeherder/commit/5b7209be2914fd1b1f5a3e5125b33c7b6d06b701
Any violation reports will be visible here:
https://insights.newrelic.com/accounts/677903/explorer/events?eventType=CSP%20violation&duration=604800000
Once this has been deployed to production, and we're happy that the policy is not too strict (ie blocking things we shouldn't be), we can switch it to being a full CSP header and not the report-only version, so it actually starts taking effect.
Assignee | ||
Comment 15•6 years ago
|
||
Hi April - hope you are well.
I don't suppose you could help us with some strange issues we're seeing now that we've added a Content-Security-Policy-Report-Only
header? In the collected CSP violation reports, I see instances like:
{
"blocked-uri": "https://queue.taskcluster.net/v1/task/ckSi7VV8TnGBsOgIQctG3Q/artifacts/public%2Factions.json",
"document-uri": "https://treeherder.mozilla.org/",
"original-policy": "default-src 'none'; script-src 'self'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data:; connect-src 'self' https://*.taskcluster.net https://treestatus.mozilla-releng.net https://bugzilla.mozilla.org https://auth.mozilla.auth0.com; report-uri https://treeherder.mozilla.org/api/csp-report/",
"referrer": "https://treeherder.mozilla.org/perf.html",
"violated-directive": "connect-src"
}
This doesn't make sense to me, since the supposed violation is something permitted by the existing connect-src
rule. The report was submitted by a User Agent of Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0
.
Is this a bug in Firefox, or an issue with our policy?
Assignee | ||
Comment 16•6 years ago
|
||
(In reply to Ed Morley [:emorley] from comment #15)
This doesn't make sense to me, since the supposed violation is something permitted by the existing
connect-src
rule
Ah so it turns out that if the fetch()
gets an HTTP 301/302 redirect, then:
- both the original and new domains need to be whitelisted in the
connect-src
directive - unhelpfully neither the fact that a redirect occurred nor the value for the new domain is included in the CSP violation report sent to
report-uri
In our case the queue.taskcluster.net
URL was redirecting to taskcluster-artifacts.net
.
Sorry for the noise! :-)
Comment 17•6 years ago
|
||
Assignee | ||
Comment 18•6 years ago
|
||
Additional items added to the report-only CSP header in:
https://github.com/mozilla/treeherder/commit/7833ba2bb755d0c7e9e4e223b4b132045090cd45
The CSP collector updated to skip CSRF checks, so it still works in browsers that send the Django session cookie but not the CSRF token [1], in:
https://github.com/mozilla/treeherder/commit/d5494a7848d46cfc7650281613e6a3ef778f26ba
[1] This issue wasn't noticed before since Firefox doesn't send the session cookie due to platform bug 1140266, whereas Chrome does.
Comment 19•6 years ago
|
||
Glad I could help. :)
One quick thing that can help with issues like this is to install Laboratory and see what CSP it spits out:
https://addons.mozilla.org/en-US/firefox/addon/laboratory-by-mozilla/
It should spit out a connect-src that covers both of them, which can be helpful for debugging these weird kinds of issues.
Comment 20•6 years ago
|
||
Assignee | ||
Comment 21•6 years ago
|
||
(In reply to April King [:April] from comment #19)
One quick thing that can help with issues like this is to install Laboratory and see what CSP it spits out:
https://addons.mozilla.org/en-US/firefox/addon/laboratory-by-mozilla/It should spit out a connect-src that covers both of them, which can be helpful for debugging these weird kinds of issues.
Unfortunately Laboratory was what gave the incorrect header in this case. I filed:
https://github.com/april/laboratory/issues/20
Assignee | ||
Comment 22•6 years ago
|
||
CSP report-only header converted to the real header in:
https://github.com/mozilla/treeherder/commit/d9de41bf4b4e06acebc3a801cba2629763801b44
NB: When features are added in the future, PR authors and reviewers will need to remember to factor in updating the policy if needed (for example to add domains to the connect-src
directive). The CSP header is not enabled when using webpack-dev-server
(it would break dev source maps and react-hot-loader) so if in doubt test locally (using yarn build
and serving via Django runserver) or on prototype first.
Bug 1529862 is filed for removing 'unsafe-inline'
from the style-src
directive.
Comment 23•6 years ago
|
||
Well shucks. That's embarrassing. I'll see why that's happening now. Thanks for the nice bug report.
Assignee | ||
Comment 24•6 years ago
|
||
No worries!
(Separately) Checking HTTP observatory after this landed shows our score increased from a B to an A+ :-)
Description
•