[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()));

Patch Details

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.

Background

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.

Analysis

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.

Exploit shape: from any attacker-controlled page, drive a same-document navigation that reports a target URL (e.g., https://victim.example/login). With the renderer-side same-origin check absent or bypassed, the UIProcess would happily render the spoofed origin. The attacker then presents a convincing replica of the spoofed site for credential capture. There is no memory-corruption primitive — the impact is a UI-integrity bypass.

This vulnerability weakens the WebContent→UIProcess trust boundary backing URL display integrity, which the entire phishing-resistance UX rests on.

Audit directions

UIProcess handlers that mutate security-UI state from renderer-supplied data. Audit every WebPageProxy::did*ForFrame* and did*Navigation* handler in Source/WebKit/UIProcess/WebPageProxy.cpp for cases where a URL or origin argument is stored without re-validation against frame->url(). Grep MESSAGE_CHECK_URL( and verify each call site has an accompanying semantic check.
Spec-implied invariants trusted from the renderer. IPC names that encode contracts (SameDocument, Fragment, Replace, InSameOrigin) often imply checks the UIProcess never re-runs. Cross-reference IPC handlers with the HTML spec sections that constrain them.
Inconsistent protocolHostAndPortAreEqual usage. Grep across Source/WebKit/UIProcess/ and inspect handlers that take a URL but skip the check; pay particular attention to history-API and fragment-navigation paths.