1012592 - CSP violation report is not sent when establishing WebSocket from appcache’d sources

Status: RESOLVED WONTFIX

(Core :: DOM: Security, defect, P4)

Description

[Muneaki Nishimura]

Attachment: fxdemo1.zip

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36

Steps to reproduce:

Suppose that a page on a server is protected by following CSP policy.
Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline'; report-uri getreport.php"
And the page is specified under the CACHE: section in a cache manifest.

(1) A user opens the page. Then the page data is stored in his/her UA.
(2) The user closes the UA, and opens the page again. Then the local data is used.
(3) The page tries to establish WebSocket connection to another origin. Then CSP policy violation report is not sent to the report-uri, and the connection is kept.



Actual results:

Assume that (3) is accidentally occurred, e.g., due to XSS, then administrators of the page cannot be aware that the policy violation exists because CSP policy violation report is not sent to the report-uri.


Expected results:

UA should send CSP policy violation report to report-uri. Or, the WebSocket connection should be silently rejected without any report.

Comment 1

[Frederik Braun [:freddy]]

It would also be a bypass of the CSP since it didn't allow websockets to other origins, correct? 
(assuming someone confirms this bug :)

Comment 2

[Muneaki Nishimura]

Yes, other kinds of CSP violation, e.g., cross-site image loading with img src, from appcached' sources are silently ignored by CSP even if the header is Content-Security-Policy-Report-Only.

If the Firefox's design of Content-Security-Policy-Report-Only is :
 * Not send any reports from appcache'd sources
 * Reject all requests with CSP violation from appcache'd sources,
then, WebSocket requests bypasses CSP as well.

Comment 3

[Daniel Veditz [:dveditz]]

In the initial description the policy is -Report-Only which never blocks anything. A failure to report would be minor, a failure to block would be more interesting but we would need to confirm that with a real policy.

Comment 4

[Daniel Veditz [:dveditz]]

I think this bug might be implying we don't cache the CSP when we cache the document. We do (last time I looked) in the regular http cache but maybe don't with appcache -- will have to test. If we're not caching CSP what other important HTTP header info might we be missing?

Comment 5

[Matt Wobensmith [:mwobensmith][:matt:]]

I will investigate if I can get some free time soon.

Comment 6

[Daniel Veditz [:dveditz]]

Maybe Garrett knows what is going on here.

Comment 7

[Garrett Robinson [:grobinson]]

As dveditz said in Comment 3, -Report-Only should never block anything. A failure to report is a minor problem, but this bug seems to imply the CSP of an appcache'd page isn't being preserved, which could lead to bypass if you're using an enforced Content-Security-Policy header. I'll attempt to reproduce this now.

Comment 8

[Garrett Robinson [:grobinson]]

In reproducing this bug, I added a cross-origin image load to the provided test case to see if the problem is with CSP+appcache in general, or specific to the Websocket call site.

When I load the page the first time, I

1. cross-origin image
   a. see the image (makes sense, because it is a -Report-Only policy)
   b. see a violation warning in the Web Console
2. websocket
   a. clicking the button gives a CSP violation warning in the Web Console

After refreshing the page (so we are using the appcached data):

1. cross-origin image
   a. do not see the image, see a torn document icon in its place (seems like a bug, because it was a report-only policy)
   b. see the same "read-only" violation warning in the Web Console
2. websocket
   a. I don't see the CSP violation warning when I click the button.

So, I have reproduced the issue with -Report-Only (no console message is printed/report sent when the bad Websocket connection is attempted). I also may have found an additional issue in which a -Report-Only header cause resources to be blocked.

Comment 9

[Garrett Robinson [:grobinson]]

When I do the same test with an enforced header, the results are a little different.

# cross-origin image

The image is consistently blocked, and no frame with a broken document icon appears. This leads me to believe that the issue with the image disappearing on reload is not related to CSP. I confirmed this by removing the CSP header entirely, and duplicating the behavior. So that is unrelated to CSP - possibly an issue with appcache, or the test manifest.

# websocket

When I click "Connect Websocket" the first time, I get:

: 
Content Security Policy: The page's settings blocked the loading of a resource at ws://evil.com/ ("default-src http://localhost:80").

The colon is a script error from poc.html:12. I'm not sure what's it supposed to be, but it's not a useful error. The second line is the CSP security error. Interestingly, it only appears once - subsequent clicks only result in the ":" script error.

Additionally, it appears that only one violation report is sent to the report-uri, right after the page loads (to report the cross-origin image violation). Subsequent violations (caused by clicking the button to open a Websocket) do not trigger report sending.

Comment 10

[Matt Wobensmith [:mwobensmith][:matt:]]

Garrett, we're trying to establish a security rating, so a little more info is needed.

Am I correct in understanding that the websocket connection never succeeds?

Comment 11

[Matt Wobensmith [:mwobensmith][:matt:]]

I discussed with Garrett and tried this again myself.

With the report-only header, I can confirm the reporter's and Garrett's observations - socket is not blocked and report is only sent the first time.

When I change it to an enforced header, I see that the report is only generated the first time. However, the socket is blocked consistently.

Considering that, and the status of appcache, I am not sure a) what is actionable and/or b) if this bug should remain private, as it does not appear to be a security bug (or a severe one).

Comment 12

[Daniel Veditz [:dveditz]]

Since the blocking/not-blocking happens correctly this is not a security issue that needs to stay hidden. Reporting is not guaranteed.

Comment 14

[Steve Workman [:sworkman] (INACTIVE)]

Hey Jason, Honza - What's the status of appcache? I remember some discussion about deprecating it.

Comment 15

[Honza Bambas (:mayhemer)]

(In reply to Steve Workman [:sworkman] (please use needinfo) from comment #14)
> Hey Jason, Honza - What's the status of appcache? I remember some discussion
> about deprecating it.

There is a plan to slowly start obsoleting it.  But slowly, first announced in advance, add warning to web console etc.  There are no details on dates, tho.

So, if this bug is considered security critical, you should fix it.

Comment 16

[Steve Workman [:sworkman] (INACTIVE)]

Thanks Honza!

Comment 17

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Honza Bambas (:mayhemer) from comment #15)
> (In reply to Steve Workman [:sworkman] (please use needinfo) from comment
> #14)
> > Hey Jason, Honza - What's the status of appcache? I remember some discussion
> > about deprecating it.
> 
> There is a plan to slowly start obsoleting it.  But slowly, first announced
> in advance, add warning to web console etc.  There are no details on dates,
> tho.

Honza, checking in after a year with no progress on the bug. Any updates on the status of appcache? Otherwise we should get this bug assigned and fixed! Thanks!

Comment 18

[Honza Bambas (:mayhemer)]

Sure.  Someone who knows the CSP code well should fix, I agree.  Who would that be?

Comment 19

[Valentin Gosu [:valentin] (he/him)]

Appcache has been deprecated and disabled.