[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.