[4] NetworkProcess missing IPC authorization on `WebPageProxyIdentifier`
A compromised renderer could borrow another WKWebView's cookie policy by name.
Medium — the diff closes a cross-process insecure-direct-object-reference, but it is a second-stage bug: it needs an already-compromised WebContent process and a victim page that opted into relaxed third-party cookie blocking. Without both, the identifier selects no relaxed policy and nothing escalates.
WebKit's NetworkProcess services cookie queries, resource loads, and WebSocket channel creation for each WebContent process over IPC. The moving parts: a WebPageProxyIdentifier, minted and owned by the UIProcess but carried to the NetworkProcess inside messages sent by WebContent; and a process-global, page-keyed policy set that records which pages have relaxed third-party cookie blocking. The invariant that was missing: a connection should only be able to name pages it is actually entitled to.
The angle: a compromised WebContent process can supply another page's WebPageProxyIdentifier — including one from a different WKWebView in a different process — and have that page's relaxed third-party cookie policy applied to its own request, disclosing cross-origin cookies.
Commit message: the NetworkProcess used the renderer-supplied identifier as an authoritative key without checking the sending connection was entitled to name that page. The pre-existing allowsFirstPartyForCookies(m_webProcessIdentifier, firstParty) check is scoped to registrable domains, not pages. The fix grants each identifier at the moment a process is granted that page's first-party cookie access.
Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Source/WebKit/UIProcess/WebPageProxy.cpp
Patch Details
The change introduces a per-process allow-list, m_allowedWebPageProxyIdentifiers, populated when a process is granted a page's first-party cookie access via the new WebPageProxy::addAllowedFirstPartyForCookies wrapper, with every navigation/process-swap call site converted to it. The NetworkProcess then checks the allow-list in validateCookieAccess, scheduleResourceLoad, performSynchronousLoad, and createSocketChannel before honoring a renderer-supplied page identifier.
A client-supplied identifier accepted as an authoritative capability at an IPC trust boundary, with no check that the sender is entitled to name it.
Background
The 4-process model. WebKit splits into UIProcess, WebContent, Networking, and GPU processes. WebContent is untrusted; NetworkProcess dispatches the actual requests and holds policy state.
WebPageProxyIdentifier. Minted and owned by the UIProcess, but travels to the NetworkProcess as an ordinary field in messages sent by WebContent (getRawCookies, cookiesForDOM, scheduleResourceLoad, createSocketChannel, ...).
Relaxed third-party cookie blocking. _shouldRelaxThirdPartyCookieBlocking is a WKWebViewConfiguration opt-in that relaxes the NetworkProcess's normal refusal to serve cookies when firstParty and url are cross-site. The page identifier is what selects the relaxation.
Analysis
This is a missing authorization check at an IPC trust boundary — the cross-process analogue of an insecure direct object reference — not a memory-safety bug.
The diff makes the keying explicit: NetworkProcess::createNetworkConnectionToWebProcess does m_pagesWithRelaxedThirdPartyCookieBlocking.addAll(parameters.pagesWithRelaxedThirdPartyCookieBlocking), a Vector<WebPageProxyIdentifier> living on the singleton NetworkProcess — shared across every WebContent connection, not partitioned per connection.
That the page identifier selects the relaxation is anchored by a preserved context line above cookieRequestHeaderFieldValueDigest: "The only caller never passed frame, page or web page proxy identifiers, so relaxed third-party cookie blocking never applied here." Because the identifier arrived from the renderer and was never matched against that renderer, a compromised WebContent process could supply any page's identifier and have the relaxed policy applied to its own request. The page-keyed relaxation lookup, identifier guessability, and loader/socket misattribution are presented as projections: a successful cross-page disclosure requires a victim page that opted into _shouldRelaxThirdPartyCookieBlocking and an attacker able to name that page's identifier.
The fix is a per-process set rather than a per-page equality test because of site isolation: a page legitimately spans multiple processes (main frame plus out-of-process subframes), so ownership is many-to-many. The grant is folded into first-party cookie access precisely so the identifier becomes nameable only when the process already holds that page's cookie authority.
Audit directions
- Renderer-supplied identifiers used as capabilities without an entitlement check. Any NetworkProcess message receiver that keys process-global policy on a
WebPageProxyIdentifier,FrameIdentifier, orPageIdentifiertaken from the message body needs an allow-list check. Audit the otherNetworkConnectionToWebProcessreceivers that read a page/frame identifier and consult shared policy state. In code review, a receiver that indexes aNetworkProcess-singleton map by an identifier decoded from the message, with nom_allowed*membership test, is the tell. - Policy state scoped per-process vs. per-connection. Where
addAll(parameters....)folds client-provided sets into a process-global container, confirm the authority axis matches site isolation's many-to-many ownership.