Closed Bug 581985 Opened 15 years ago Closed 15 years ago

Content Security Policy on Mozilla Security Blog is generating an error

Categories

(mozilla.org Graveyard :: Webdev, task)

Product:
mozilla.org Graveyard
Component:
Webdev
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bsterne, Assigned: lorchard)

Details

CSP debug: Constructed violation report: {"csp-report":{ "request":"GET http://blog.mozilla.com/security/ HTTP/1.1", "request-headers":"<snip>", "blocked-uri":"self", "violated-directive":"violated base restriction: Inline Scripts will not execute"} } This is because of the Omniture script: <script type="text/javascript">s_account="mozillablog";</script><script src="/wp-content/js/s_code.js" type="text/javascript"></script> If we simply move that one variable assignment into the s_code.js file (and remove the empty inline script block), the Error will go away.
Blake, do we still want to use omniture on blog.mozilla.com?
Assignee: server-ops → bcutler
No, feel free to remove it.
Assignee: bcutler → jeremy.orem+bugs
Omniture has been removed from blog.mozilla.com.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
This is still unfixed... sorry. I didn't catch the other instance of inline script in the page in the header section of our template: <div id="header" onclick="location.href='http://blog.mozilla.com/security';" style="cursor: pointer;"> I don't have permissions to edit the template. Can we please remove the onclick handler from that element?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Pushed theme change.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Sorry this isn't resolved yet. Not sure when this change was made, but there is still the following inline script in our template: <!-- ----------------------------------------------------------------------------------- --><!-- Warning: The two script blocks below must remain inline. Moving them to an external --><!-- JavaScript include file can cause serious problems with cross-domain tracking. --><!-- ----------------------------------------------------------------------------------- --><script type="text/javascript">//<![CDATA[var _tag=new WebTrends();_tag.dcsGetId();//]]>></script><script type="text/javascript">//<![CDATA[// Add custom parameters here.//_tag.DCSext.param_name=param_value;_tag.dcsCollect();//]]>></script> Just commenting out each line doesn't alleviate the error, since a JS comment is still parsed. Please just remove the two script blocks.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is a site wide plugin for stats tracking. Is there anyway we can include this javascript and fix your error?
Yes, those JS statements need to be moved into an external file (served from blog.mozilla.com) and included in the page via: <script src="/path/to/file"></script>
Anybody on webdev familiar with the webtrends javascript? Can we move it to an external file?
Assignee: jeremy.orem+bugs → nobody
Component: Server Operations: Web Content Push → Webdev
QA Contact: mrz → webdev
We got them to make their script less bad so that we could follow CSP. clouserw knows more details.
You can read about our trials and results in bug 556378. tl;dr is comment 31
Trying to move blog.m.c stuff over to webdev. Code is here: http://viewvc.svn.mozilla.org/vc/projects/blog.mozilla.com/trunk/wp-content/ is someone available to fix this?
Assignee: nobody → lorchard
r75002 seems to have a partial fix for this, but I'm still getting one more error that I can't seem to track down: Warning: CSP: Directive "violated base restriction: Inline Scripts will not execute" violated The debug report isn't much help, since it doesn't tell me *what* inline script wasn't executed, or where it was encountered. The WebTrends code all seems to run, an IMG tag gets included, and even alert()'s I insert into the webtrends JS work. But, that inline script error goes away when I comment out the webtrends-v0.1.js script tag. Anyone have any hints on how to track down this last CSP error? Not sure how to show a reproduction of it without a staging WPMU install.
And just for the sake of completeness, this is the debug report I'm seeing (sans headers): CSP debug: Constructed violation report: {"csp-report":{"request":"GET http://dev.blog.mozilla.com/security/ HTTP/1.1","request-headers":"<snip>","blocked-uri":"self","violated-directive":"violated base restriction: Inline Scripts will not execute"}} (Where dev.blog.mozilla.com is a vhost on my laptop apache install)
Please see comment 6. I just verified that _removing_ the commented-out inline script blocks still makes the error go away.
(In reply to comment #15) > Please see comment 6. I just verified that _removing_ the commented-out inline > script blocks still makes the error go away. I see your comment 6 and raise you the diff of the revision I mentioned (r75002): http://viewvc.svn.mozilla.org/vc/projects/blog.mozilla.com/trunk/wp-content/mu-plugins/moz_custom.php?r1=75002&r2=75001&pathrev=75002 I removed the inline script blocks entirely on my dev server, and there's still one violation error.
I can't speak to that as I don't have access to your dev server, but I just verified that removing the script blocks from the production server response gets rid of the two violations that occur without doing so. I'm just intercepting the response in a proxy and removing those tags. There may be some code in webtrends-v0.1.js (production site just says webtrends.js) that is causing the violation, such as document.write'ing some inline script. I read through bug 556378 and it was unclear to me if we were able to get the changes we needed to fix this bug. The version of webtrends.js that's currently on the site, though, doesn't seem to cause the violation.
(In reply to comment #17) > I can't speak to that as I don't have access to your dev server, but I just > verified that removing the script blocks from the production server response > gets rid of the two violations that occur without doing so. I'm just > intercepting the response in a proxy and removing those tags. That's basically what I said - not sure how to show a repro case without having a staging server. The problem with just removing those script blocks is that what they do has to be done somewhere at some point, because that's what drives the WebTrends code. > There may be some code in webtrends-v0.1.js (production site just says > webtrends.js) that is causing the violation, such as document.write'ing some > inline script. I read through bug 556378 and it was unclear to me if we were > able to get the changes we needed to fix this bug. The version of webtrends.js > that's currently on the site, though, doesn't seem to cause the violation. There's no document.write in the code as far as I can tell, but that's why I dropped in here for help. I don't know where that code came from other than that it seemed to be a fix. If it's not, then I'm not sure where to go from here other than to tear it apart line-by-line
Can you link to a copy of the webtrends-v0.1.js that your dev server is using? I can take a look through it.
(In reply to comment #19) > Can you link to a copy of the webtrends-v0.1.js that your dev server is using? > I can take a look through it. It's in the commit I linked to (r75002): http://viewvc.svn.mozilla.org/vc/projects/blog.mozilla.com/trunk/wp-content/js/webtrends/webtrends-v0.1.js?view=markup&pathrev=75002 Also, more plaintext here: http://svn.mozilla.org/projects/blog.mozilla.com/trunk/wp-content/js/webtrends/webtrends-v0.1.js
Brandon, did you get a chance to look at it? Les can set it up on khan if it helps. Les - in the meantime can you pastebin the generated source for the page somewhere?
I did look at it but wasn't able to turn up anything via manual review. Les, I started experimenting with augmenting the violation logging (see bug 600584) so I have a build that I think would help track this down if you can set it up on khan or some other server where I can access it.
Trying to set up a copy of WPMU with blog.mozilla.com content on khan, but not having much luck. Same config as my laptop, modulo mysql credentials, but I can't seem to get an admin user to actually work. My laptop has PHP 5.3.2 and khan has PHP 5.2.9, but I'm not sure if that's significant
Okay, I had to bludgeon WPMU a little, but I finally got it working on khan: http://blog.lorchard.khan.mozilla.org/security/ You may need an /etc/hosts entry, eg: 10.2.74.111 blog.lorchard.khan.mozilla.org I didn't do much to replicate the actual security blog, but I do see the CSP violation with just the initial "Hello world" post and "gathering" theme.
And here's a weird thing I just noticed: If I reload the blog page, but switch tabs before the reload finishes, I don't see a CSP violation. Not sure if it's relevant, just sort of grasping here
I don't see a CSP violation at all on that khan test site. I reloaded several times and did not see any violations.
(In reply to comment #26) > I don't see a CSP violation at all on that khan test site. I reloaded several > times and did not see any violations. I think I may have found something: I disabled all my addons, restarted, and the violation went away. I re-enabled Firebug 1.7X0a2m, and the violation returned. So... I think that for the purposes of this bug, r75002 fixed the violations. But, somehow, Firebug (at least this alpha version) is introducing one itself.
More specifically, if I leave Firebug 1.7X0a2 installed and enabled but disable the Console tab, the violation goes away. Enable the Console tab, violation returns.
Not sure what the next step is, here. I think r75002 actually addresses this bug, but I can't update the blog itself. There's also the matter of a CSP violation apparently introduced by Firebug, but I don't think I can do anything about that either
I'm not seeing the CSP error on the Security Blog anymore, so from my perspective this bug is FIXED.
I'll mark this fixed, then - someone can reopen if it rears its head again
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Thanks Les!
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.