Gecko view loadURI code doesn't pass a triggering principal
Categories
(GeckoView :: General, defect)
Tracking
(Not tracked)
People
(Reporter: jkt, Unassigned)
References
(Blocks 2 open bugs)
Details
The following code and the call sites aren't passing a triggering principal which will mean that code that requires same site cookies and various others usages of principals won't work.
Thanks for the report! Do you know if we be using createCodebasePrincipalFromOrigin()
, or something else?
Updated•5 years ago
|
Reporter | ||
Comment 2•5 years ago
|
||
:snorp so the problem is that when we have an existing document that has loaded into the tab of the browser. We need to use the existing current tab document principal in the load of any subsequent navigations. Creating the principal on the fly as we do the load doesn't have any meaning of where the user has come from.
Example:
- a user is on example.com and clicks a link to bob.com
- The triggering principal would be bob.com when it actually should be example.com
- The bob.com load then is passed same site cookies that it shouldn't be.
The other problem with this code is also that the browser will break out of private browsing mode and we need to pass the correct origin attributes for these loads.
We should probably have a quick meeting about this if you are at all hands, I'm making this security sensitive as I just realised this is breaking insecurely rather than not sending cookies.
(In reply to Jonathan Kingston [:jkt] from comment #2)
:snorp so the problem is that when we have an existing document that has loaded into the tab of the browser. We need to use the existing current tab document principal in the load of any subsequent navigations. Creating the principal on the fly as we do the load doesn't have any meaning of where the user has come from.
Example:
- a user is on example.com and clicks a link to bob.com
- The triggering principal would be bob.com when it actually should be example.com
- The bob.com load then is passed same site cookies that it shouldn't be.
That shouldn't happen because this code is only called for navigations requested by the app (e.g., via the location bar). Clicked links don't use this mechanism.
The other problem with this code is also that the browser will break out of private browsing mode and we need to pass the correct origin attributes for these loads.
I'm fairly certain this is not happening due to the above.
We should probably have a quick meeting about this if you are at all hands, I'm making this security sensitive as I just realised this is breaking insecurely rather than not sending cookies.
Yup, I'm happy to talk about it further.
A little update: Christoph, Jonathan, and myself talked in-person about this and we believe the only problem here should be external file
URIs. We currently use a privileged principal for those. We should only do so if the URI points to a file in the APK.
External file URIs are fine too because the codebase principal is appropriate.
Updated•5 years ago
|
Description
•