1432831 - validate HttpChannelOpenArgs in HttpChannelParent::init() for sanity

Status: NEW

(Core :: Networking: HTTP, enhancement, P3)

Description

[Ben Kelly [:bkelly, not reviewing]]

Towards our goal of improving security and process isolation we should consider validating arguments when messages are received in the parent.  A good place to start might be our nsIChannel protocols like PHttpChannel.

If we validated the HttpChannelOpenArgs in HttpChannelParent::Init() we could check:

1. Verify that various URIs and principals are internally consistent.  We have particular sets of values that are allowed for the combination of loading principal, triggering principal, principalToInherit, ClientInfo values, service worker controller values, various flags, etc.  We should check that these are sane.  This could be done via an approach like bug 1430159 or just done directly in HttpChannelParent::Init().
2. For subresource requests verify that the loading principal matches a window/worker client that exists in the sending content process.  This would require the API from bug 1432825.  It would also need to be an async check.

Maybe there are more things we could check as well once we start digging into it.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Also, if we pick a specific protocol to start with (like PHttpChannel) then it might help us build primitives and best practices we can use to get other protocols locked down.

Comment 2

[Paul Theriault [:pauljt] (no longer reading bugmail)]

See also bug 1325647 - Julian doesnt work at mozilla but if we looking for IPDL validation helpers this might be a start.

Comment 3

[Tom Ritter [:tjr] (OOTO until mid-August)]

Yes! When I dug into this, I had felt we could verify every LoadingPrincipal we received from the Content Process to match against the expected origin for that content process.

Comment 4

[Chris Peterson [:cpeterson]]

hardening bug

This bug is not a Fission MVP blocker.