Remove (disabled by default) CSP directive `navigate-to`.
Categories
(Core :: DOM: Security, task, P4)
Tracking
()
Tracking | Status | |
---|---|---|
firefox123 | --- | fixed |
People
(Reporter: freddy, Assigned: canadahonk, Mentored)
References
(Blocks 3 open bugs, )
Details
(Whiteboard: [domsecurity-backlog])
Attachments
(1 file)
The CSP directive navigate-to
never shipped in Chrome or Firefox.
There are concerns about leaking redirect & cross-origin information and the editors suggest removing it from the specification
Let's remove our implementation too.
Reporter | ||
Comment 1•2 years ago
|
||
This can be tackled as a good first bug.
Requirements that must be met to take this bug:
(1) Some knowledge in C++
(2) a fully working environment that allows you to modify and build Firefox.
For (2), please work through the recommended steps at https://wiki.mozilla.org/Good_first_bug and https://firefox-source-docs.mozilla.org/setup/contributing_code.html.
If you encounter any road blocks in setting up your development environment, please consult a search engine or our #introduction
chat on Matrix. - Not here.
Assignee | ||
Comment 2•1 years ago
|
||
It has never shipped in Firefox (or any browser) after being implemented
years ago, and was removed from spec in September 2022:
https://github.com/w3c/webappsec-csp/pull/564
TODO:
- Remove existing WPT tests and add historical not impl check?
Updated•1 years ago
|
Comment 4•1 year ago
|
||
Backed out changeset 117114b8eb32 (bug 1793560) for causing wpt failures at iframe-all-local-schemes-inherit-self.sub.html
Backout: https://hg.mozilla.org/integration/autoland/rev/18d91fb6569af8afe8d64c8cc5ec1b9508356501
Failure log: https://treeherder.mozilla.org/logviewer?job_id=422137313&repo=autoland&lineNumber=2549
Assignee | ||
Comment 5•1 year ago
|
||
Not sure what's up with the failure specifically, changed to changes planned and will look into.
Assignee | ||
Comment 6•1 year ago
|
||
Not sure what the issue is after debugging locally for a while, but I can repro the fails of that WPT (content-security-policy/inheritance/iframe-all-local-schemes-inherit-self.sub.html
). @tschuster do you mind taking a look if free at some point? Thanks!
Comment 7•1 year ago
|
||
Sorry CanadaHook, I won't be able to look at this before next week.
Comment 8•1 year ago
•
|
||
Okay, this turned out to be a much bigger rabbit hole than I initially expected. We already know that we have a bug with 'self'
sources when the CSP is inherited to iframes . (We should be using the origin and not what we currently call mSelfURI
, see bug 1721296 and bug 1803475)
However it looks like the call to GetAllowsNavigateTo
in Document::StartDocumentLoad
was partially working around this issue by accident! The first thing that GetAllowsNavigate
does is to call EnsureIPCPoliciesRead
, which will call AppendPolicy
. AppendPolicy
will then parse a CSP using the context's current mSelfURI
, which at that point is still the previous mSelfURI
(not about:srcdoc etc.).
When we remove this early call to GetAllowsNavigate
we will instead end up calling AppendPolicy
from Document::InitCSP
(via GetCSPSandboxFlags
specifically). This only happens after a call to nsCSPContext::SetRequestContextWithDocument
, which changes the mSelfURI
of the context to about:srcdoc and overrides whatever was in the CSP from loadInfo->GetCspToInherit()
.
We need to be really careful here not accidentally break web compatibility. I am not sure yet what the best way forward is.
Assignee | ||
Comment 9•1 year ago
|
||
Is it worth adding a hack to call EnsureIPCPoliciesRead
/etc where the old GetAllowsNavigate
was called for now or should we avoid it?
Comment 10•1 year ago
|
||
(In reply to Oliver Medhurst [:canadahonk] from comment #9)
Is it worth adding a hack to call
EnsureIPCPoliciesRead
/etc where the oldGetAllowsNavigate
was called for now or should we avoid it?
We probably should do something like this. A real solution for the 'self'
problem isn't planned yet and we had some breakage when I accidentally broke it (more) before.
Comment 11•11 months ago
|
||
This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit BugBot documentation.
Updated•11 months ago
|
Assignee | ||
Comment 12•11 months ago
|
||
Happy to (try to) finish this off.
We probably should do something like this.
I'll update the patch with that hack and a reference to the problem, hopefully that makes it good to go.
Comment 13•11 months ago
|
||
Comment 14•11 months ago
|
||
bugherder |
Description
•