Web Inspector: BackendResourceDataStore for Site Isolation response bodies

JSC kept engine-internal scope metadata inside the Primitive Gigacage — the region designed to confine attacker-corruptible user buffers.

ccf6c82

Source/WebKit/WebProcess/Inspector/WebInspectorBackend.messages.in

+ GetResponseBody(String requestId) -> (String body, bool base64Encoded, String errorMessage) Async

Source/WebCore/inspector/InspectorIdentifierRegistry.h

+ std::optional<DeterministicRequestId> parseDeterministicRequestId(const String&);

Source/JavaScriptCore/inspector/protocol/Network.json

- { "name": "getResponseBody", ... }

+ { "name": "getResponseBody", "async": true, ... }

WebKit의 Site Isolation 환경에서 cross-origin iframe은 별도의 WebContent process에서 실행됩니다. Web Inspector의 UIProcess는 ProxyingNetworkAgent를 통해 CDP 방식의 명령을 해당 WebProcess 내 per-frame agent로 전달합니다. 기존의 Network.getResponseBody는 동기 방식으로 동작했으며, NetworkResourcesData 내의 CachedResource 참조에 의존했습니다. 그러나 이 구조는 process 경계를 넘을 수 없었습니다.

이 commit에서는 BackendResourceDataStore가 새로 추가되었습니다. 각 WebProcess에 위치하는 HTTP response 메타데이터 및 content 버퍼로, WebInspectorBackend가 이를 소유합니다. Response 데이터는 instrumentation 시점에 복사되어 CachedResource의 lifetime과 독립적으로 관리됩니다. 또한 Network.getResponseBody가 동기에서 비동기 방식으로 전환되었습니다. ProxyingNetworkAgent는 parseDeterministicRequestId를 통해 frontend에서 제공한 requestId 문자열을 파싱해 대상 WebProcess 식별자를 추출하고, 해당 process에 비동기 GetResponseBody IPC 메시지를 전송하게 됩니다.

Significance

이 commit은 새로운 IPC 경로와 requestId 기반 라우팅 메커니즘을 도입해 Site Isolation process 경계를 넘어 Web Inspector의 접근 범위를 확장합니다. 신뢰 검증 과정에 버그가 존재한다면, inspector frontend가 접근해서는 안 되는 WebProcess의 response body를 탈취할 가능성이 있습니다.

Audit directions

parseDeterministicRequestId는 attacker-controlled 문자열을 파싱합니다. inspector frontend에서 전달받아 어느 WebProcess에 IPC 메시지를 보낼지 결정하는 데 사용됩니다. 검증이 불충분하면 confused-deputy 공격이나 잘못된 IPC 라우팅이 발생할 수 있습니다. 나아가 inspector frontend가 제어해서는 안 되는 WebProcess에 GetResponseBody가 전달될 가능성도 있습니다.
WebProcess GetResponseBody handler. requestId가 해당 WebProcess에서 실제로 로드한 리소스에 속하는지 확인해야 합니다. origin이나 frame 검증 없이 문자열 키만으로 조회한다면, 조작된 requestId를 통해 의도하지 않은 frame context의 body를 탈취할 수 있습니다.
BackendResourceDataStore의 LRU eviction은 CachedResource lifetime과 분리됩니다. 비동기 IPC 완료 경로에서 use-after-free나 double-callback 위험이 없는지 점검해야 합니다. 특히 page teardown과 진행 중인 GetResponseBody 응답 사이에 race condition이 발생하는 경우를 주의 깊게 살펴봐야 합니다.
commit에서 라우팅 설계가 known-weak FIXME로 명시적으로 인정되어 있습니다. 적절한 mapping 기반 수정이 반영되기 전까지는 기술적 부채로 표시된 경로에 해당합니다.