Issue metadata
Sign in to add a comment
|
Security review for new network service webui code |
||||||||||||||||||||
Issue descriptionIn the parent bug, I've added support for chrome:// scheme when the network service is used. Tom: can you please provide a security review for this? Thanks. Implementation notes: -this depends on network service, PlzNavigate, and mojo for loading. once the latter 2 ship, we can use this code path as well for production (i.e. before network service ships) -there's a way to create a mojom::URLLoaderFactory for chrome:// urls. this is in content/browser/webui/web_ui_url_loader_factory.cc -for frame requests, the webui URLLoaderFactory is hooked in NavigationURLLoaderNetworkService::StartURLRequest( for webui scheme -RenderFrameHostImpl::CommitNavigation also replaces the URLLoaderFactory for the frame's subresources Security notes: -if a non-webui page has a webui scheme, then this is blocked as before because the ChildProcessSecurityPolicy checks are done in the browser by the plznavigate code before we get to NavigationURLLoaderNetworkService -a redirect from a non-webui scheme to a webui scheme will fail, since the redirects happen in the network service which doesn't know about webui scheme -we only send the factory to the renderer for subresources if the renderer committed a webui URL, which means the renderer is already trusted I _think_ things are ok so far security-wise, but I defer to you Tom for security review.
,
May 8 2017
Curious, is there a place where we specify which schemes the Network Process will handle, and what behaviour it takes for unrecognized ones? As you mention above, we can get some very nice security properties if we are careful here.
,
May 8 2017
MakeURLRequestContext in content/network/network_context.cc is where net::URLRequestContextBuilder is built. It comes with support for http/https and we enable data. This code is still pretty early, so we can have the ability to change how other schemes are hooked in. My goal with the webui implementation was to show how schemes could be pluggin in without changing the network service's API.
,
May 8 2017
Another way of answering your question: maybe we can plug in file support through a separate URLLoaderFactory, like how webui is done. That way the browser process controls who gets access to it, without having to synchronize something like ChildProcessSecurityPolicy to the network process. Currently we turn on file support through the "builder.set_file_enabled(true);" in network_context.cc, but we don't have to.
,
Jul 21 2017
,
Nov 7 2017
,
Nov 7 2017
Apologies, applied the wrong component in bulk.
,
May 22 2018
this does not block canary.
,
May 22 2018
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by tsepez@chromium.org
, May 8 2017