Assertion failure: nsCSPContext::Equals(csp, argsCSP), at /home/emilio/src/moz/gecko-3/docshell/base/nsDocShell.cpp:9947
Categories
(Core :: DOM: Security, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox68 | --- | fixed |
People
(Reporter: emilio, Assigned: ckerschb)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [domsecurity-active])
Attachments
(1 file)
STR:
- Go to https://bug1182775.bmoattachments.org/attachment.cgi?id=8632447 on a debug build.
- Press Ctrl + U, or right click -> View Page Source.
Expected:
- No crash
Actual:
- Tab crashes, with:
Assertion failure: nsCSPContext::Equals(csp, argsCSP), at /home/emilio/src/moz/gecko-3/docshell/base/nsDocShell.cpp:9947
Reporter | ||
Updated•6 years ago
|
Assignee | ||
Comment 1•6 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #0)
STR:
- Go to https://bug1182775.bmoattachments.org/attachment.cgi?id=8632447 on a debug build.
- Press Ctrl + U, or right click -> View Page Source.
Emilio, thanks for filing. I just tried to reproduce the problem using your STRs and the latest code from mozilla-central, but I can't. Anything I am missing?
Reporter | ||
Comment 2•6 years ago
|
||
I can reproduce on a clean profile visiting the bug before-hand, so STR:
./mach run --temp-profile
- Go to https://bugzilla.mozilla.org/show_bug.cgi?id=1182775
- Click on the
index.html
attachment. - Ctrl + U
Does that repro for you?
Assignee | ||
Comment 3•6 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
Does that repro for you?
Ha, now I can - I am on it! Thanks!
Assignee | ||
Comment 4•6 years ago
|
||
The assertion that triggers here verifies that the explicit CSP and the CSP within the triggeringPrincipal are equal. We are doing this in preparation when moving the CSP from the Principal into the CLient.
The carveout to not assert when the load was triggered by a NullPrincipal which we added for Bug 1544534 is actually not sufficient, because we only serialize the CSP within CodebasePrincipals, so we should actually make the assertion only fire in that case. I updated the code to reflect that change.
What's happening here in detail is that we are creating a history entry with the correct principal (CSP within that Principal) and correct explicit CSP. When doing a view-source of page however the triggeringPrincipal on the shEntry however gets overwritten by the SystemPrincipal [1] which then causes the assertion to fire. It's worth mentioning that ultimately we would like to apply CSP to system privileged pages so I would rather avoid to set the CSP to null on the shEntry where we set the principal to system [1].
I think having the assertion only fire for CodebasePrincipals (which is the only principal where we serialize the CSP to disc within) is the way to go - any objections?
[1] https://searchfox.org/mozilla-central/source/docshell/base/nsDocShell.cpp#4823
Assignee | ||
Comment 5•6 years ago
|
||
Comment 7•6 years ago
|
||
bugherder |
Updated•3 years ago
|
Updated•3 years ago
|
Description
•