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

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[Sunil]

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.

Comment 1

[u279076]

Does this happen with Firefox 9.0a1?

Comment 2

[Sunil]

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

Comment 3

[Boris Zbarsky [:bzbarsky]]

Confirming.  Specifically, at least in the inline script case we don't log correctly.

Comment 4

[Sid Stamm [:geekboy or :sstamm]]

pointing to the CSP tracking bug

Comment 5

[Sid Stamm [:geekboy or :sstamm]]

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.

Comment 6

[Sid Stamm [:geekboy or :sstamm]]

Attachment: 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).

Comment 7

[Boris Zbarsky [: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?

Comment 8

[Sid Stamm [:geekboy or :sstamm]]

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

Comment 9

[Sid Stamm [:geekboy or :sstamm]]

Attachment: 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

Comment 10

[Boris Zbarsky [: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

Comment 11

[Sid Stamm [:geekboy or :sstamm]]

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.

Comment 12

[Boris Zbarsky [:bzbarsky]]

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.

Comment 13

[Sid Stamm [:geekboy or :sstamm]]

Attachment: 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.

Comment 14

[Boris Zbarsky [:bzbarsky]]

>+        if (!allowsInline) return NS_ERROR_DOM_RETVAL_UNDEFINED;

in nsJSThunk::EvaluateScript.

Comment 15

[Sid Stamm [:geekboy or :sstamm]]

This is no longer blocked by bug 552523 (works without it).

Comment 16

[Sid Stamm [:geekboy or :sstamm]]

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

Comment 17

[Sid Stamm [:geekboy or :sstamm]]

Need to unbitrot and make sure it doesn't break new stuff.

Comment 18

[Sid Stamm [:geekboy or :sstamm]]

Attachment: fix

Unbitrotted and carrying over r=bz.  Also addressed the failure of my eyegrep.

Try: https://tbpl.mozilla.org/?tree=Try&rev=bdfa3da43011

Comment 19

[Sid Stamm [:geekboy or :sstamm]]

Inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/c29279c95238

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/c29279c95238