← All issues

[1] [WebKit] Remove SetCORSDisablingPatterns IPC from NetworkConnectionToWebProcess

Severity: High | Component: WebKit NetworkProcess | 841ad59

Rated High because the diff removes a WebContent-reachable IPC that wrote arbitrary URL patterns into m_pageCORSDisablingPatterns/originAccessPatterns, directly silencing same-origin enforcement on outbound cross-origin loads for the renderer's page; the primitive is reached without further escalation from a compromised WebProcess.

Removes SetCORSDisablingPatterns(PageIdentifier, Vector<String>) from NetworkConnectionToWebProcess and re-routes the policy delivery to flow directly WebPageProxyNetworkProcess. Previously the NetworkProcess parsed each pattern into a UserContentURLPattern, stored it keyed by PageIdentifier, and added it to the per-connection NetworkOriginAccessPatterns consulted by shouldDisableCORSForRequestTo().

Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp

-void NetworkConnectionToWebProcess::setCORSDisablingPatterns(PageIdentifier pageIdentifier, Vector<String>&& patterns)
-{
- Vector<UserContentURLPattern> parsedPatterns;
- parsedPatterns.reserveInitialCapacity(patterns.size());
- for (auto&& pattern : WTFMove(patterns)) {
- UserContentURLPattern parsedPattern(WTFMove(pattern));
- if (parsedPattern.isValid()) {
- originAccessPatterns().allowAccessTo(parsedPattern);
- parsedPatterns.append(WTFMove(parsedPattern));
- }
- }
- parsedPatterns.shrinkToFit();
- m_networkProcess->setCORSDisablingPatterns(pageIdentifier, WTFMove(parsedPatterns));
-}

Confused-deputy IPC: NetworkProcess treated WebContent as the source of trust for per-page CORS-disabling policy when the policy actually originates from the UIProcess SPI.

The renderer-originated path is deleted. WebPage::synchronizeCORSDisablingPatternsWithNetworkProcess is removed; APIPageConfiguration::setCORSDisablingPatterns now persists into WebPageProxy, which sends the parsed patterns to NetworkProcess over the UI→Network IPC channel. The m_pageCORSDisablingPatterns map and shouldDisableCORSForRequestTo() lookup remain — only the writer changes.

WebKit's CORS implementation lives on both the WebContent (preflight, response checks) and NetworkProcess (cross-origin scheduling) sides. The per-page allow list m_pageCORSDisablingPatterns, plus the per-connection NetworkOriginAccessPatterns, is consulted in shouldDisableCORSForRequestTo() to skip CORS for matching URLs. The legitimate writer of this policy is the embedder, which calls -[WKWebView _setCORSDisablingPatterns:] and propagates through APIPageConfiguration in the UI process. The IPC sandbox boundary between UI/Network (trusted) and WebContent (untrusted) demands that any policy that loosens CORS must not flow through the renderer.

The pre-fix path went UIProcess → WebContent → NetworkProcess: the WebContent process held the patterns and synchronised them to the NetworkProcess. A compromised WebContent process could craft SetCORSDisablingPatterns(pageIdentifier, ["*://*/*"]) over its existing NetworkConnectionToWebProcess endpoint. The NetworkProcess parsed each UserContentURLPattern without verifying caller authority and appended it to originAccessPatterns(). Every subsequent outbound load from that page hit shouldDisableCORSForRequestTo() with a positive match and skipped CORS — including same-origin preflight and credentials decisions on the network side.

🔒

Walks the policy-delivery trust path before and after the fix and assesses what a compromised renderer could achieve at the network boundary.

Subscribe to read more

🔒

Multiple reusable audit patterns identified for trust-boundary IPCs across NetworkProcess and GPUProcess, with concrete starting points for variant discovery.

Subscribe to read more