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

RESOLVED FIXED in mozilla22

Status

()

Core
Security
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: Sunil, Assigned: geekboy)

Tracking

(Blocks: 1 bug)

Trunk
mozilla22
x86
Windows XP
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

6 years ago
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.
(Reporter)

Updated

6 years ago
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?
(Reporter)

Comment 2

6 years ago
(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
(Assignee)

Comment 4

5 years ago
pointing to the CSP tracking bug
Blocks: 493857
(Assignee)

Comment 5

5 years ago
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.
(Assignee)

Comment 6

5 years ago
Created attachment 671654 [details] [diff] [review]
wip

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+
(Assignee)

Comment 8

5 years ago
(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.
(Assignee)

Comment 9

5 years ago
Created attachment 672965 [details] [diff] [review]
proposed patch

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+
(Assignee)

Comment 11

5 years ago
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.

Updated

5 years ago
Blocks: 801783
(Assignee)

Updated

5 years ago
Blocks: 805929
(Assignee)

Comment 13

5 years ago
Created attachment 675659 [details] [diff] [review]
fix

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.
(Assignee)

Comment 15

5 years ago
This is no longer blocked by bug 552523 (works without it).
(Assignee)

Comment 16

5 years ago
(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.
(Assignee)

Comment 17

4 years ago
Need to unbitrot and make sure it doesn't break new stuff.
Flags: needinfo?(sstamm)
(Assignee)

Comment 18

4 years ago
Created attachment 730797 [details] [diff] [review]
fix

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)
(Assignee)

Updated

4 years ago
Attachment #730797 - Attachment is patch: true
(Assignee)

Comment 19

4 years ago
Inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/c29279c95238
Flags: in-testsuite+
Target Milestone: --- → mozilla22
https://hg.mozilla.org/mozilla-central/rev/c29279c95238
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.