Closed Bug 687086 Opened 13 years ago Closed 12 years ago

CSP report only mode doesn't work for inline-script and eval-script

Categories

(Core :: Security, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla22

People

(Reporter: sunil, Assigned: geekboy)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 3 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Steps to reproduce: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110302 Iceweasel/3.5.16 (like Firefox/3.5.16) Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Hi. If I use the following (apache) configuration Header set X-Content-Security-Policy-Report-Only \ "allow 'none'; \ report-uri /perl/csp-report.pl" for a document that has inline scripts, no violation reports are generated for them. Sincerely, Sunil Reproducible: Always Expected results: I was expecting a violation report to be generated and sent to the server, however that didn't happen. However, if I do operate with CSP header 'X-Content-Security-Policy' it does correctly prevent the script from execution and also send a violation report.
Summary: CSP remote only mode doesn't work for inline-script and eval-script → CSP report only mode doesn't work for inline-script and eval-script
Does this happen with Firefox 9.0a1?
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #1) > Does this happen with Firefox 9.0a1? Yes, same behavior is observed in Firefox 6 and Firefox 9.0a1.
Component: Security → General
Product: Firefox → Core
QA Contact: firefox → general
Version: 5 Branch → Trunk
Component: General → DOM: Core & HTML
QA Contact: general → general
Confirming. Specifically, at least in the inline script case we don't log correctly.
Status: UNCONFIRMED → NEW
Component: DOM: Core & HTML → Security
Ever confirmed: true
Depends on: 552523
pointing to the CSP tracking bug
Blocks: CSP
this is probably because the inline script compiler is asking CSP if it's okay to run the script, and CSP is saying "don't block it" but not telling the caller that a violation report needs to go out. We probably need an outparam in GetAllowsInline (and GetAllowsEval) that returns whether or not it's a violation for when CSP is report-only and not blocking stuff.
Attached patch wip (obsolete) (deleted) — Splinter Review
bz: I couldn't get this out of my head all morning, so I started on a patch even though I told you I had no time. I'm new at the outparams thing with XPCOM, is this on the right track? I promise to add tests (and confirm it doesn't break CSP or other related unit tests).
Assignee: nobody → sstamm
Status: NEW → ASSIGNED
Attachment #671654 - Flags: feedback?(bzbarsky)
Comment on attachment 671654 [details] [diff] [review] wip The outparams bit looks fine, though it may be a good idea to keep the "should I allow this?" as a return value... Note that if you do, I think that will change the order of the two bool* args in C++. Do you still want the JS_ReportError in the setTimeout code? I don't see any callers of SetReportCSPViolations on workers. Should there be some?
Attachment #671654 - Flags: feedback?(bzbarsky) → feedback+
(In reply to Boris Zbarsky (:bz) from comment #7) > Do you still want the JS_ReportError in the setTimeout code? Good catch, I don't. Spec says: "When called with a first argument that is non-callable (e.g., not a function), the setTimeout function must return zero without creating a timer." > I don't see any callers of SetReportCSPViolations on workers. Should there > be some? Probably not. I just added it as a reflex (copied the pattern around mEvalAllowed). I'll drop that function. Thanks for the quick feedback.
Attached patch proposed patch (obsolete) (deleted) — Splinter Review
Addressed all the feedback comments, added tests to test_cspreports.js. It's stewing on try: https://tbpl.mozilla.org/?tree=Try&rev=93501265c67d
Attachment #671654 - Attachment is obsolete: true
Attachment #672965 - Flags: review?(bzbarsky)
Comment on attachment 672965 [details] [diff] [review] proposed patch In dom and content code, this: if (foo) return something; should be written like so: if (foo) { return something; } Please fix the instances of that in this patch, and r=me
Attachment #672965 - Flags: review?(bzbarsky) → review+
So removing the JS_ReportError call destroyed the eval-blocking mochitests. see: http://mxr.mozilla.org/mozilla-central/source/content/base/test/file_CSP_evalscript_main.js I can re-write the tests to check for blocked eval, but without making a racy test I am not sure how to check whether setTimeout executed or not.
Well, a setTimeout with a function argument would still run, right? So if you have: function bar() {} setTimeout("foo", n); setTimeout(bar, n); then you're guaranteed that the string "foo" will NOT be eval'ed after function bar is called.
Blocks: 801783
Blocks: 805929
Attached patch fix (obsolete) (deleted) — Splinter Review
Updated patch with "eval" tests that should work based on the pattern suggested by bz. For some reason I remember being told that order of execution was not guaranteed for two timeouts with the same interval. Seems to work though, we'll see if try likes it. https://tbpl.mozilla.org/?tree=Try&rev=f162b743fd2e I only found one instance of "if (foo) bar;", but fixed it as requested in comment 10. Carrying over r=bz.
Attachment #672965 - Attachment is obsolete: true
Attachment #675659 - Flags: review+
>+ if (!allowsInline) return NS_ERROR_DOM_RETVAL_UNDEFINED; in nsJSThunk::EvaluateScript.
This is no longer blocked by bug 552523 (works without it).
(In reply to Boris Zbarsky (:bz) from comment #14) > >+ if (!allowsInline) return NS_ERROR_DOM_RETVAL_UNDEFINED; > > in nsJSThunk::EvaluateScript. *sigh*, thanks bz. My copy of Eyeball Grep is apparently not working today. I'll fix that and reattach after try gets back to me with a thumbs up or down.
Need to unbitrot and make sure it doesn't break new stuff.
Flags: needinfo?(sstamm)
Attached patch fix (deleted) — Splinter Review
Unbitrotted and carrying over r=bz. Also addressed the failure of my eyegrep. Try: https://tbpl.mozilla.org/?tree=Try&rev=bdfa3da43011
Attachment #675659 - Attachment is obsolete: true
Attachment #730797 - Flags: review+
Flags: needinfo?(sstamm)
Attachment #730797 - Attachment is patch: true
Flags: in-testsuite+
Target Milestone: --- → mozilla22
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: