[9] [WebKit] Add origin validation to setAppBadge / setAppBadgeFromWorker

Severity: Medium | Component: WebKit UIProcess Badging | 675c62d

Rated Medium because the diff terminates a renderer that supplies an origin outside the process's owned site set; pre-fix, the UIProcess attributed the badge update to the spoofed origin in the UI client and website data store, but no further escalation primitive is established.

WebFrameProxy::setAppBadge and WebProcessProxy::setAppBadgeFromWorker now consult allowsFirstPartyAccess, which compares the supplied registrable domain to m_site->domain() (or the allowed set for SharedProcess). Mismatch → MESSAGE_CHECK (renderer kill); the MultipleSites process state is silently dropped (benign-but-impossible).

Source/WebKit/UIProcess/WebFrameProxy.cpp

Origin spoofing on the badging IPC: a compromised renderer attributes a badge update to any origin and the UI process forwards the spoofed origin to the website data store.

Patch Details

Both IPC endpoints add the allowsFirstPartyAccess(origin) check. The matching logic accepts the process's owned site or, for SharedProcess, the allowed set. MultipleSites is treated as a no-op.

Background

The Badging API surfaces per-origin updates to the OS app icon. The UIProcess receives badge IPC from each WebContent process; in the standard process model the process owns a single site, and any IPC claiming a different origin is illegitimate.

Analysis

Pre-fix, the IPC handlers forwarded the supplied SecurityOriginData directly to uiClient().updateAppBadge(...) and workerUpdatedAppBadge(...). A compromised renderer could embed any origin in the message and the UI process attributed the badge to it.

The user-visible effect is a notification-shaped spoof targeting an arbitrary origin's badge count. No further capability is established by the IPC itself. The fix terminates the renderer on mismatch, which is the standard sandbox-boundary response.

This weakens the per-origin attribution invariant of the Badging API across the WebContent ↔ UI boundary.

Audit directions

• Other per-origin UIProcess IPCs with an unvalidated SecurityOriginData parameter. Grep IPC::Connection/Messages::... handlers for origin fields lacking allowsFirstPartyAccess / equivalent.
• SharedProcess and MultipleSites state handling. Confirm every origin-bearing handler accepts the same set semantics — the silent drop on MultipleSites is correct only if no such process exists in practice.
• Service-worker IPC origin claims. SW-originated paths often bypass the per-frame check; verify all of them have an equivalent check.