Closed Bug 1297051 Opened 3 years ago Closed 3 years ago

Firefox CSP Report Only blocks mixed content (Video via http)

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox48 --- wontfix
firefox49 + fixed
firefox50 --- fixed
firefox51 --- fixed

People

(Reporter: holger, Assigned: ckerschb)

References

(Blocks 1 open bug)

Details

(Whiteboard: [domsecurity-active])

Attachments

(2 files)

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

Steps to reproduce:

Visit the following test page:
https://obscure-bastion-11877.herokuapp.com/with-csp


Actual results:

The video referenced via http did not play.  Error:
Content Security Policy: Unsecure request 'http://cdn.ubivent.com/web/test/ubiventimagevideo.webm' is blocked.


Expected results:

The video should be allowed to play as only the header "content-security-policy-report-only" is used. 

content-security-policy-report-only:"block-all-mixed-content; report-uri https://ubivent.report-uri.io/r/default/csp/reportOnly"

A working example without the csp header works:
https://obscure-bastion-11877.herokuapp.com/without-csp

We first detected this Problem in Version 48.

Please note that if both pages (with and without csp) are opened at the same time, both videos will work.  It seems that the video from the page without csp is then reused.  

From our perspective, it seems that the "content-security-policy-report-only" header is also being used as "Content-Security-Policy" header.

We have not tried to see what happens if the "Content-Security-Policy" header is also set.
confirmed in FF49.0b5
Component: Untriaged → DOM: Security
Product: Firefox → Core
I can confirm in current Nightly.
Blocks: csp-w3c-2
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → All
Version: 49 Branch → Trunk
This might be related or a dupe of bug 1249058, but in my case the report-uri is not conspicuously slow.
Priority: -- → P2
Whiteboard: [domsecurity-backlog]
Priority: P2 → P1
Assignee: nobody → ckerschb
Whiteboard: [domsecurity-backlog] → [domsecurity-active]
Status: NEW → ASSIGNED
Dan, I just realized we have the same 'report-only' problem for upgrade-insecure-requests - should we fix it within this bug or file a separate one? Would be good to uplift both of them actually. What do you think?

[1] https://dxr.mozilla.org/mozilla-central/source/dom/security/nsCSPContext.cpp#313
Attachment #8783938 - Flags: review?(dveditz)
Holger, thanks for assembling the testpage and filing the bug.
No problem, thanks for fixing the bug so quickly.
Attachment #8783937 - Flags: review?(dveditz) → review+
Comment on attachment 8783938 [details] [diff] [review]
bug_1297051_csp_ro_block_all_mixed_content.patch

Review of attachment 8783938 [details] [diff] [review]:
-----------------------------------------------------------------

This works to prevent blocking mixed content in report-only mode, but there's no reporting of it. Actually looks like there's no reporting even in a regular CSP so I guess we should cover that in a separate bug.

r=dveditz
Attachment #8783938 - Flags: review?(dveditz) → review+
Comment on attachment 8783937 [details] [diff] [review]
bug_1297051_csp_ro_block_all_mixed_content_tests.patch

Approval Request Comment
When we implemented the CSP directive block-all-mixed-content (landed in FF 48) we didn't account for a CSP enforced in report-only mode. The directive block-all-mixed-content should not be enforced in such a case.

[Feature/regressing bug #]:
Bug 1122236 - Implement block-all-mixed-content CSP directive

[User impact if declined]:
Web pages deploying a CSP in report only mode and use the directive block-all-mixed-content will encounter breakage because all mixed content is blocked.

[Describe test coverage new/current, TreeHerder]:
Land a mochitest within this patch.

[Risks and why]:
Low, since it only affects pages deploying a CSP in report only mode which use the directive block-all-mixed-content.

[String/UUID change made/needed]:
No
Attachment #8783937 - Flags: approval-mozilla-beta?
Attachment #8783937 - Flags: approval-mozilla-aurora?
Comment on attachment 8783938 [details] [diff] [review]
bug_1297051_csp_ro_block_all_mixed_content.patch

Approval Request Comment

See comment 9.
Attachment #8783938 - Flags: approval-mozilla-beta?
Attachment #8783938 - Flags: approval-mozilla-aurora?
Pushed by mozilla@christophkerschbaumer.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/acb05a7c5ee7
CSPRO should not block mixed content. r=dveditz
https://hg.mozilla.org/integration/mozilla-inbound/rev/dc9031025f08
Test CSPRO should not block mixed content. r=dveditz
Tracking for 49, looks like we should uplift this to beta, but let's make sure it lands on m-c first.
https://hg.mozilla.org/mozilla-central/rev/acb05a7c5ee7
https://hg.mozilla.org/mozilla-central/rev/dc9031025f08
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Hello Holger, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(holger)
Comment on attachment 8783937 [details] [diff] [review]
bug_1297051_csp_ro_block_all_mixed_content_tests.patch

Test-only patch.
Attachment #8783937 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8783938 [details] [diff] [review]
bug_1297051_csp_ro_block_all_mixed_content.patch

Aurora50+
Attachment #8783938 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Hi Ritu, yes I can confirm that the issue is fixed with the Nightly build.
Comment on attachment 8783938 [details] [diff] [review]
bug_1297051_csp_ro_block_all_mixed_content.patch

Fix for mixed content behavior, verified in nightly. 
This should land for beta 8.
Attachment #8783938 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8783937 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: needinfo?(holger)
You need to log in before you can comment on or make changes to this bug.