← All issues

[1] didSameDocumentNavigationForFrame accepts arbitrary URL, enabling address bar spoofing

Severity: High | Component: WebKit UIProcess | 23b15df

Rated High because the diff fixes a UIProcess IPC that updates the displayed URL from a renderer-supplied string with no origin check; reaching it from web content is sufficient to spoof any origin in the address bar.

WebPageProxy::didSameDocumentNavigationForFrameViaJS accepted any well-formed URL from the WebContent process and used it as the frame's new URL after a history.pushState/replaceState-style navigation. The pre-existing MESSAGE_CHECK_URL only validated parseability; nothing enforced that a same-document navigation must remain same-origin.

Source/WebKit/UIProcess/WebPageProxy.cpp

Ref process = WebProcessProxy::fromConnection(connection);
MESSAGE_CHECK_URL(process, url);
+ MESSAGE_CHECK(process, url.protocolIsFile() || frame->url().isEmpty() || protocolHostAndPortAreEqual(url, frame->url()));

A single MESSAGE_CHECK is added immediately after MESSAGE_CHECK_URL, enforcing that the URL is a file URL, the frame URL is empty, or scheme/host/port match the frame's current URL. Failure kills the offending WebContent process.

Missing origin-equivalence check on a renderer-supplied URL crossing the WebContent→UIProcess trust boundary.

A same-document navigation changes the URL without unloading the document (typically via the History API or fragment changes); per spec the new URL must be same-origin with the current document. WebKit's UIProcess owns the address bar and maintains a per-WebFrameProxy URL that feeds it. MESSAGE_CHECK_URL validates URL parseability; protocolHostAndPortAreEqual compares the scheme/host/port tuple that defines an origin.

Before the fix, a compromised or scripted WebContent process could call didSameDocumentNavigationForFrameViaJS with any URL and have the UIProcess record it as the frame's current URL — feeding the address bar an attacker-chosen origin while the actual document remained attacker-controlled.

🔒

The trust boundary between WebContent and UIProcess for URL display is examined, along with the spoofing impact and what a renderer compromise (or just clever JS) could achieve here.

Subscribe to read more

🔒

Several reusable IPC-validation audit patterns identified, covering UIProcess handlers that mutate security-UI state based on renderer-supplied data.

Subscribe to read more