Browser shouldn't blindly trust |url::Origin| values sent by renderer processes |
||
Issue description
We should either
1) refactor code so that sending of url::Origin is not necessary
2) verify the value via CPSPI::CanAccessDataForOrigin
Examples of legacy IPCs that send url::Origin from the renderer to the browser:
- FrameHostMsg_OpenURL_Params::initiator_origin
- Probably allows spoofing of Origin header and/or SameSite cookies
- RenderFrameProxyHost::OnOpenURL
- RenderFrameHostImpl::OnOpenURL
- FrameHostMsg_DownloadUrl_Params::initiator_origin
- Probably allows spoofing of Origin header and/or SameSite cookies
- RenderFrameMessageFilter::OnDownloadUrl
- FrameHostMsg_OpenChannelToPepperPlugin::origin_lock
- Probably quite important for robustness of PDF isolation
- RenderFrameMessageFilter::OnOpenChannelToPepperPlugin
- FrameHostMsg_PluginContentOriginAllowed::content_origin
- PluginContentOriginWhitelist::OnPluginContentOriginAllowed
- FrameHostMsg_GetPluginInfo::main_frame_origin
- RenderFrameMessageFilter::OnGetPluginInfo
- FrameHostMsg_DidLoadResourceFromMemoryCache::top_frame_origin
- WebContentsImpl::OnDidLoadResourceFromMemoryCache
- FrameHostMsg_DidCommitProvisionalLoad_Params::origin
- Already verified by RFHI::CanCommitOrigin, but in the future can be removed
(i.e. can be calculated entirely on the browser side)
,
Jan 4
Why do we need to carve out exception for opaque origins? Soon we will have precursor information in opaque origins, unless they are unique opaque ones in which case the process will likely be locked to about: or data:, which we can easily enforce. Am I missing something?
,
Jan 4
|
||
►
Sign in to add a comment |
||
Comment 1 by lukasza@chromium.org
, Jan 4