Open Bug 1272034 Opened 9 years ago Updated 2 years ago

Sending Violation report(http and https) on upgrade-insecure-requests

Categories

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

Product:
Core
Component:
DOM: Security
Version:
49 Branch
Type:
defect

Tracking

()

People

(Reporter: takashi.kazenomamani, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [domsecurity-backlog2])

Attachments

(1 file)

violation-report-firefox.png
(deleted), image/png
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 Build ID: 20160510030240 Steps to reproduce: I set this CSP to my server. Header set Content-Security-Policy-Report-Only: "default-src 'none'; report-uri /log.php" ------------------------------------------- 1. Go to page which is enabled "Content-Security-Policy: upgrade-insecure-requests" 2. When I load image or iframe, Firefox will send 2 violation reports. One for http, another is upgraded document(https) Actual results: Firefox will send 2 violation reports. Expected results: W3C stated.... ---------------------------- CSP Violation Reports When sending a violation report for an upgraded resource, user agents MUST target the Document or Worker that triggered the request, rather than the Document or Worker on which the upgrade-insecure-requests directive was set. Due to ˜3.3 Policy Inheritance, the latter might be a cross-origin ancestor of the former, and sending violation reports to that set of reporting endpoints could leak data in unexpected ways. Source: http://www.w3.org/TR/upgrade-insecure-requests/#violation-report-target ---------------------------------------- Does that mean Firefox shouldn't send violation 2 reports? To tell you the truth, this language is hard to understand. If I'm wrong, I'm really sorry. Please collect me if I am wrong.
Attached image violation-report-firefox.png (deleted) —
typo: violation 2 reports ==> 2 violation reports
Group: firefox-core-security → core-security
Component: Untriaged → DOM: Security
Flags: needinfo?(ckerschb)
Product: Firefox → Core
Most likely we should send only one violation report, but we should investigate what's going on in detail. Would be great to have a testpage for that. Is it possible that we send a report for the preload and for the actual load? Either way, I am fine with opening this bug up, but I'll wait for the next triage and Dan should decide. Putting this in the backlog for now.
Flags: needinfo?(ckerschb)
Whiteboard: [domsecurity-backlog]
This is my test page(html) which was used for my testing. ----------------------------------- <!DOCTYPE HTML> <head> <meta charset="UTF-8"> <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> <title>upgrade test</title> </head> <body> <iframe src="http://vk.com"></iframe> </body> </html>
Assume https://a.com embeds http://vk.com and uses the upgrade-insecure-requests directive and also disables referrers. https://a.com shoudl receive a violation report and the browser should attempt to upgrade the frame to https://vk.com. vk.com shouldn't get any violation report; if it does, then we are leaking that it is embedded in https://a.com (assuming the report contains the domain name), or at least that it is embedded in a page that has the upgrade-insecure-request directive. Takashi, are you saying that the vk.com server gets a violation report?
No. vk.com is meaningless. I used vk.com because this site can be accessed from http and https. I just wanted to test on real service rather than my local server.
The test from comment 4 and the screenshot from comment 1 don't fit together. The console message states a CSP of "default-src 'none'" and it also uses 'observed the loading' which we only use for CSPReportOnly. It would be really great to have a live testpage. It's really hard to follow given only fragments of a test.
I uploaded my video to google drive. Please watch it. I'm so sorry for inconvenience. https://drive.google.com/open?id=0B1vJ77JB-BeoM2NOWVQ1Nnp1T0E
I think my video and screenshot from comment 1 fit together. Am I missing something?
Flags: needinfo?(ckerschb)
By the way, is it really necessary to send 2 violation reports from upgrade-insecure-request? W3C stated... "user agents MUST target the Document that triggered the request." Firefox does not send any request from http url. Request will be sent after upgrade http to https.
(In reply to Takashi from comment #9) > I think my video and screenshot from comment 1 fit together. Am I missing > something? Hey Takashi, thanks for taking the time to record that video. That's really helpful. Finally I understand what's going on, here we go: a) The page is sending a CSPRO in the header of default-src 'none' b) The page further sends a meta CSP of 'upgrade-insecure-requests'. c) Now that you are loading an http iframe we are calling channel->AsyncOpen2() on the channel that is loading the iframe. AsyncOpen2() performs security checks and sends the *first* report. Note, since that is a Report-Only policy, we don't block the load, but only send the report. d) AsyncOpen2() internally then calls ::Connect() which then internally upgrades http to https and we call AsyncOpen2() on the (internally) redirected channel, which then consults content policies and sends the *second* report. To sum it up, I agree, we shouldn't send two reports, but both reports are sent to https://test.com/log.php. In other words, we are simply over-reporting here, which is annoying for web site authors for sure, but *definitely* not a security risk. If you wouldn't use a CSPRO, but a real CSP of "default-src 'none'" then we would block the load right away and you would receive only one violation report.
Flags: needinfo?(ckerschb)
Group: core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
I agree with you. Sending violation report to my server is not a risk, unless it contains some leaked infomation. I reported to your team because.... I couldn't understand what W3C specification means. Probably there is unknown risk from sending another violation report. I tried many situations, but I couldn't figure out what the risk is. Can your team figure out why spec said "MUST target request?" Please teach me.
I have to apologize for sending false positive report. I am really sorry.
Priority: -- → P2
Priority: P2 → P3
Whiteboard: [domsecurity-backlog] → [domsecurity-backlog2]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: