Open Bug 1012592 Opened 6 years ago Updated 21 days ago
CSP violation report is not sent when establishing Web
Socket from appcache’d sources
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.
It would also be a bypass of the CSP since it didn't allow websockets to other origins, correct? (assuming someone confirms this bug :)
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.
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.
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?
Component: Untriaged → DOM: Security
Product: Firefox → Core
I will investigate if I can get some free time soon.
Maybe Garrett knows what is going on here.
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.
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.
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.
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?
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).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Since the blocking/not-blocking happens correctly this is not a security issue that needs to stay hidden. Reporting is not guaranteed.
Hey Jason, Honza - What's the status of appcache? I remember some discussion about deprecating it.
(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.
(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!
Whiteboard: [reporter-external] → [reporter-external], [domsecurity-backlog]
Sure. Someone who knows the CSP code well should fix, I agree. Who would that be?
You need to log in before you can comment on or make changes to this bug.