← All issues

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

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

process의 소유 site set 외부 origin을 제공하는 renderer를 diff에서 종료합니다. 패치 이전에는 UIProcess가 UI client와 website data store에서 badge 업데이트를 spoofed origin에 귀속했습니다. 다만 IPC 자체로는 추가적인 확장 primitive가 확보되지 않아 Medium으로 평가되었습니다.

WebFrameProxy::setAppBadgeWebProcessProxy::setAppBadgeFromWorker는 이제 allowsFirstPartyAccess를 참조합니다. 이 함수는 전달된 registrable domain을 m_site->domain()(또는 SharedProcess의 허용 set)과 비교합니다. 불일치하면 MESSAGE_CHECK가 발동되어 renderer가 종료됩니다. MultipleSites process 상태는 무시됩니다(이 상태는 실제로 존재하지 않으므로 무해합니다).

Source/WebKit/UIProcess/WebFrameProxy.cpp

+ MESSAGE_CHECK(allowsFirstPartyAccess(origin));
uiClient().updateAppBadge(...);

Badging IPC에서의 origin spoofing: 침해된 renderer가 임의의 origin에 badge 업데이트를 귀속시키면, UI process는 spoofed origin을 website data store로 전달합니다.

두 IPC endpoint 모두 allowsFirstPartyAccess(origin) 검사를 추가했습니다. 이 matching logic은 process가 소유한 site를 허용하며, SharedProcess의 경우에는 허용 set을 대상으로 검사합니다. MultipleSites 상태는 no-op으로 처리됩니다.

Badging API는 OS 앱 아이콘에 origin별 업데이트를 표시합니다. UIProcess는 각 WebContent process로부터 badge IPC를 수신합니다. 표준 process 모델에서는 하나의 process가 단일 site를 소유하므로, 다른 origin을 주장하는 IPC는 허용되지 않습니다.

패치 이전에는 IPC handler가 전달받은 SecurityOriginDatauiClient().updateAppBadge(...)workerUpdatedAppBadge(...)로 그대로 전달했습니다. 침해된 renderer는 메시지에 임의의 origin을 삽입할 수 있었고, UI process는 해당 origin에 badge를 귀속했습니다.

🔒

How an IPC origin field can be weaponized at the renderer→UI trust boundary, and what the new three-valued authorization result actually buys.

더 확인하려면 구독해 주세요

🔒

Four reusable audit directions covering sibling IPC handlers, variant-of-known-bug enumeration, and the shared-process allow-list surface introduced by this fix.

더 확인하려면 구독해 주세요