Need to implement support for the Content Security Policy (CSP) in Bugzilla. https://developer.mozilla.org/en/Introducing_Content_Security_Policy https://wiki.mozilla.org/Security/CSP https://wiki.mozilla.org/Security/CSP/Deploying (under construction) https://wiki.mozilla.org/Security/CSP/Design_Considerations

Why is this targetted 4.0? This doesn't look like a single param to pass to CGI headers to make CSP work. It looks like it involves much more changes, and it's not a bugfix, despite being security related.

Yeah, this is definitely not something that's going to go into 4.0.

Note that CSP is going to bring severe restrictions. Every single onload="..." is going to be ignored, every single two-lines inline script too. I suppose this will also prevent to execute JS code in attachments? https://developer.mozilla.org/en/Security/CSP/Default_CSP_restrictions IMO, this won't make into 4.2.

Or we could specify: options inline-script

(In reply to comment #4) > Or we could specify: options inline-script Yeah, that's the only way that we would do this. We won't be removing all the inline scripts from Bugzilla. That would just result in a ton more HTTP requests for separate files that don't really need to be separate. So if we're not forbidding inline scripts, then what is the value of the CSP? (In fact, I can't see any application of any reasonable size ever removing all of its inline JS, which makes me question the value of the CSP at all.)

(In reply to comment #5) > (In reply to comment #4) > > Or we could specify: options inline-script > > Yeah, that's the only way that we would do this. We won't be removing all the > inline scripts from Bugzilla. That would just result in a ton more HTTP > requests for separate files that don't really need to be separate. We should combine and minify the external JS files then (probably at runtime, but maybe at checksetup time) to cut down on number of separate requests. That's not difficult, and it'll give us a perf benefit over our current set up. > So if we're not forbidding inline scripts, then what is the value of the CSP? > (In fact, I can't see any application of any reasonable size ever removing all > of its inline JS, which makes me question the value of the CSP at all.) I think you would agree with me that AMO is an "application of any reasonable size", and it is working on support for CSP in bug 594584 (report-only at first and then enforce later). It is able to get rid of all its inline-script just fine for this, afaik... If we want to talk just bug trackers, MantisBT has implemented full support for CSP, as discussed in several blog posts: * http://www.mantisbt.org/blog/?p=102 * http://www.mantisbt.org/blog/?p=119 * http://www.mantisbt.org/blog/?p=126 Other bug trackers are taking the initiative to protect their users. Why can't Bugzilla?

(In reply to comment #5) > (In reply to comment #4) > > Or we could specify: options inline-script > > Yeah, that's the only way that we would do this. We won't be removing all the > inline scripts from Bugzilla. That would just result in a ton more HTTP > requests for separate files that don't really need to be separate. I'm not sure why you're dumping cold water on the idea without first trying to understand the CSP model a bit better. Mozilla has invested a lot of time and thought into CSP as a robust anti-XSS mechanism and the no-inline-script restriction is the central piece of the model. Without it, it is impractical-to-impossible to differentiate injected vs. legitimate script in the page. > So if we're not forbidding inline scripts, then what is the value of the CSP? > (In fact, I can't see any application of any reasonable size ever removing all > of its inline JS, which makes me question the value of the CSP at all.) As Reed pointed out, CSP is already in production on AMO (report-only) and several of the Mozilla blogs (full). It's also in production on mobile.twitter.com, and being tested for deployment on the main site. Mobile Twitter is an interesting use case, because inline script is even more valuable from a performance perspective on high latency devices. They felt the security gained by turning on CSP outweighed the performance cost of externalizing scripts. That said, concatenating all the inline scripts into an external script file and fetching it separately is a relatively minor performance impact (Reed thinks it's a win). You're right, though, that CSP offers no XSS protection if options inline-script is turned on.

(In reply to comment #6) > Other bug trackers are taking the initiative to protect their users. Why can't > Bugzilla? From the Mozilla perspective, as a user of bugzilla (BMO), this is a security feature we would definitely like to see added.

(In reply to comment #7) > I'm not sure why you're dumping cold water on the idea without first trying to > understand the CSP model a bit better. Okay. I do understand the CSP model, and I understand why it's useful. As a slightly snarky response, I don't understand why you are so adamant about work that we should do and force all our customizers and extension authors to do without first trying to understand the existing architecture, requirements, uses, and userbase of Bugzilla. > Mozilla has invested a lot of time and > thought into CSP as a robust anti-XSS mechanism and the no-inline-script > restriction is the central piece of the model. Without it, it is > impractical-to-impossible to differentiate injected vs. legitimate script in > the page. Yes, but we already have very extensive XSS protection in Bugzilla. Granted, it would be nice to have a blanket protection for it, because then we wouldn't have to worry about it (at least for browsers that implement the CSP) but the amount of required effort, the added complexity and utter confusion it will cause customizers and extension authors, and possible performance damage (and don't make suggestions about how we should implement things without first understanding that Bugzilla has an old codebase with no standard web framework underneath it) isn't worth it for the actual value that will come to our userbase--at least, not until all commonly-used browsers support the CSP. Once that happens, it would possibly be a more-valuable addition. > As Reed pointed out, CSP is already in production on AMO (report-only) and > several of the Mozilla blogs (full). It's also in production on > mobile.twitter.com, and being tested for deployment on the main site. Those are all centrally-hosted in-house apps. Generally, examples of software development practices for in-house apps are not relevant to shipping systems like Bugzilla. reed's Mantis example is more relevant, although Mantis is of course in a different programming language, with a different framework, and I don't know much about their software design or the size of their community. > You're right, though, that CSP offers no XSS protection if options > inline-script is turned on. Okay. But it still would possibly get us some clickjacking protection, no? So there's a value to doing this now, and over time (not right now) we can think about possible ways to make it easier for us to remove inline scripts while still making development sensible and sane for extension authors, customizers, and new Bugzilla contributors. But we won't be moving them all into external scripts right now, we'll just be looking at it as a possibility over time.

4.2 is feature frozen. Also, I doubt it will make it in 5.0 unless bug 96983 is fixed meanwhile. So untargetting for now rather than retargetting it every 9 months.

Could we try to move this forward by not depending on bug 96983 and start off with a less strict policy? I'm trying to advance CSP within Mozilla's properties. Let me know if I can help here! :)

:freddyb: because CSP has a report mode, you might consider setting up a trial policy which is pretty lax, adding it in report-only mode, and then viewing the reports to see whether it works or not - and, if not, what you'd need to change in order to make it work. I'm sure dkl and glob would look favourably upon a small patch which added a report-only header. Although your collection point would need to be ready for the data it would get. I'd love to help you, but I'm pretty busy at the moment. Gerv

Meh, sounds like we need a Perl volunteer then? :)

Oh, I see. Adding one HTTP header really shouldn't be hard - you might even get dkl or glob to write you a patch if you buy them a beer. And altering that header later should be a patch _anyone_ can make. Gerv

See bug 938596, which is a precursor to fixing this bug by writing a small extension to allow a Bugzilla admin to specify a CSP header (either Report-Only or real). Gerv

Hey there! I was hoping we could get the conversation started again on CSP for BMO. Although BMO isn't a terribly common source of XSS attacks, it is a particularly high-profile target. As an ideal first CSP target, I was hoping we could implement something like this: Content-Security-Policy: default-src https: Namely, that we can load resources only over https, and we disable all inline scripts. When I apply that policy to BMO Prod, I get about a half-dozen on so minor inline script issues, several of which persist across multiple pages: >bugzilla.mozilla.org/:23 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-AIORuFNrQVH7IxwhuN5eMPlxlUAf+owvn9V9f76XzJY='), 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. Something related to YAHOO.namespace -- looks easy enough to move to an external file; it's currently just a <script> in <head> >bugzilla.mozilla.org/:77 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-/R3wm+GmaaPngJJakOUAzEEvIguO9JfVsV1BUEwW3ck='), 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. Looks like it creates a hidden input for Persona or something -- should also not be too terrible to move to an external file >bugzilla.mozilla.org/:154 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-2QBaTW8JqtEuH0xzTQOdcQjRPGIeXJOcPUAfzm7gask='), 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. More YAHOO stuff, just a <script> tag in <body> >bugzilla.mozilla.org/:172 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-jj1BbCKfjIYDkQEtBwQzi98q2L/NTkCLvGPe7CzJhAs='), 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. More YAHOO stuff, just a <script> tag in <body> >bugzilla.mozilla.org/:281 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-j24qucoW1tDl3QPYeeP0bxGUvF0510fw+pWtBWgZ7QE='), 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. An inline script that checks to see if the form is empty >bugzilla.mozilla.org/:132 Refused to execute inline event handler because it violates the following Content Security Policy directive: "default-src https:". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), 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. <body onload=""> -- doesn't do anything It looks like there's quite a lot of inline scripts inside BMO, but it shouldn't (hopefully) be too agonizing to move them to external files. Moving all of the JavaScript to external files is the first step in implementing CSP to disable inline scripts. Plus, as bonus, it should provide a minor performance boost, since the inline code won't be sent along with every page request.

(In reply to April King from comment #16) > Hey there! I was hoping we could get the conversation started again on CSP > for BMO. This bug is not about BMO but about Bugzilla the product. So not all policy decisions which you could take for BMO specifically can apply as-is to all Bugzilla installations. I think this distinction is important. > hoping we could implement something like this: > > Content-Security-Policy: default-src https: This won't work for all installations as we do not enforce HTTPS. > Moving all of the JavaScript to external files is the first step in > implementing CSP to disable inline scripts. Nothing new here. See the bug blocking this one, aka bug 96983. It has been filed 15 years ago.

i filed bug 1238832 to track this for BMO.

Bug 1238832 is the one related to Mozilla properties. This bug is about upstream Bugzilla, which is different.

Sorry about that, dylan. So much bug number copy-pasting. :)

After reading http://githubengineering.com/githubs-csp-journey/, I am of the mind we should implement a dynamic CSP. This will ease adoption because we can tighten the screws on a per-resource basis. Templates are sent after we've already done headers, so we will need to decide before (or during) $cgi->header() what the policy for a given resource is. In terms of configuration, there should be a few knobs: - completely disabled - report only - completely enabled Secondly, there should be CSP configurations for attachments, as different sites may have relatively different requirements for hosting attachments. - attachments on bmo will allow inline scripts, etc, as web devs need that - attachments on sites that don't make use of an attachment domain should not allow inline scripts