[Webkit-unassigned] [Bug 184149] Do CSP checks in the network process

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=184149

--- Comment #7 from Daniel Bates <dbates at webkit.org> ---
Youenn Fablet and I discussed this bug today (04/25). Youenn expressed an interest in standardizing on IPC messaging semantics between the network process and web content process that avoids passing HTTP response data to the web content process until the last possible moment (*). If we want to do this then we will need to duplicate in the network process all the CSP redirection checks we do in the web content process. Elaborating further, we need to duplicate these checks because we will always need to keep code in WebCore to do the CSP checks for redirections to continue to support CSP in WebKit Legacy. Here are some of the options I see with regards to moving more CSP logic to the network process and the advantages and disadvantages:

Option 1: Only duplicate CSP frame-ancestor check in network process. All other CSP checks are performed in web content process.
    Advantage: With the exception of frame-ancestor all other CSP checks are centralized in one process, the web content process; => minimal code duplication.
    Disadvantage: Must duplicate CSP frame-ancestor check in network process. Added IPC cost as network process must message web content process on each redirect request to ask if the load is allowed by the page's CSP policy.

Option 2: Duplicate frame-ancestor check and all CSP checks applied to redirect requests in the network process.
    Advantage: Network process does not need to message web content process on each redirect request to ask if the load is allowed by the page's CSP policy; => avoid IPC.
    Disadvantage: Must duplicate all CSP checks for redirects in network process to avoid the need to message web content process on each redirect request to ask if the load is allowed by the page's CSP policy. (We may be able to extract some or all of the CSP checks, at least the checks in  CachedResourceLoader, into a common functions that is used both by the network process and WebCore. It is non-trivial to do this refactor).

The following options are conditional on the removal of WebKit Legacy:

Option 3: Move all CSP checks (read: including the initial request) to the network process.
    Advantage: Centralizes all CSP checks for subresource loads to the network process.
    Disadvantage: Pay IPC cost for the initial request (since we send every request for CSP processing to the network process). Adds IPC from the web content process to network process so tell it the CSP policy when specified in an HTML meta element. Adds IPC from the network process to the web content process to dispatch the SecurityPolicyViolation event for each CSP violation (may be able to batch such dispatch).

Option 4: Move all CSP checks (read: including the initial request) to the network process and teach network process to parse CSP policy specified in HTML meta element.
    Advantage: Centralizes all CSP checks for subresource loads and CSP parsing to the network process.
    Disadvantage: Pay IPC cost for the initial request (since we send every request for CSP processing to the network process). Adds IPC from the network process to the web content process to block eval execution. Adds IPC from the network process to the web content process to dispatch the SecurityPolicyViolation event for each CSP violation (may be able to batch such dispatch).

(*) This is motivated by the desire to have a process-per-origin and only have cross-origin data in the same address space when such cross-origin data has passed all security checks and hence must be delivered to the web content process in order to avoid breaking the web.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180425/19f2546d/attachment-0001.html>