BrowserParent::RecvNewWindowGlobal receives unexpected principals that don't match the process's stated principal
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
People
(Reporter: tjr, Unassigned)
References
(Blocks 1 open bug)
Details
Background
In the meta Bug 1670242 (really its children) we landed code that ensures the principals we receive from a Fission content process match the expected principal for that process. example.com shouldn't be sending principals claiming to be google.com. To better understand ContentParent's principal for the process it was added in this commit.
This validation occurs in ValidatePrincipal and is called case-by-case in Recv messages. (I think this is because things like a triggeringPrincipal wouldn't be subjected to this check - I don't remember the explicit reason this isn't checked deeper in the IPC code during deserialization, but that's orthoganal to this bug and something we can dig back into later.)
If the pref is enabled (which it is on Release) and we fail validation, we will send telemetry and crash a debug build. We do not crash or otherwise return an error on Release - just telemetry. (So the 'enforce' pref name is not that accurate.)
This bug is about one specific method we are seeing in the telemetry.
Bug
BrowserParent::RecvNewWindowGlobal is by far and away the most submitted Telemetry event. Right now there are 66k reports from 15k clients that are receiving a https:// Content principal that doesn't match the principal for the process. We also have reports (fewer in number) for http://, view-source://, file://, and moz-extension Content Principals.
Given the number of reports, it seems likely that there is an expected use case for this method where we receive a non-matching ContentPrincipal - this bug is on file to understand how and why this can happen so we can adjust our behavior accordingly.
|
||
Comment 1•2 years ago
|
||
The meta bug has P3, so I'll just do the same to this bug.
Description
•