[Site Isolation] Web Inspector deterministic Network IDs and event routing

Component: WebKit Web Inspector | 2bfe8ae

Site Isolation 환경에서는 각 origin의 콘텐츠가 별도의 WebContent process에서 실행될 수 있습니다. 하지만 Inspector frontend는 network resource와 frame이 하나로 통합된 단일 목록 형태로 존재하기를 기대합니다. 이 간극을 메우기 위해 UIProcess에서는 "octopus" agent(ProxyingNetworkAgent/ProxyingPageAgent)가 실행되며, 각 WebContent process에서 IPC로 전달된 이벤트를 취합합니다. 이때 process 로컬 식별자는 "frame-PID.objectID"와 같이 타입이 접두어로 붙은 문자열(IdentifierRegistry::protocolFrameId/protocolRequestId/protocolLoaderId)로 변환되어, 충돌 없는 전역 ID 공간에 매핑됩니다. 이번 commit은 이러한 ID 체계를 도입하는 동시에, renderer와 UIProcess 사이에서 process 범위의 resource ID를 전달하기 위한 ProcessQualified<ResourceLoaderIdentifier> 직렬화도 함께 구현합니다. 아울러 frontend JS 쪽도 순서가 어긋난 이벤트, 즉 대응하는 frame이 아직 파악되지 않은 시점에 Network 이벤트가 먼저 도착하는 상황을 처리할 수 있어야 하며, cross-origin iframe에 대해서는 frame을 임시로 stub 처리하도록 변경됩니다.

WebContent Process A            WebContent Process B            UIProcess
  ResourceLoaderIdentifier(3)     ResourceLoaderIdentifier(3)
         │                               │
         ▼                               ▼
  ProcessQualified<               ProcessQualified<
    ResourceLoaderIdentifier>       ResourceLoaderIdentifier>
  (PID_A, 3) ──IPC──────────────────────────────► ProxyingNetworkAgent
  (PID_B, 3) ──IPC──────────────────────────────► IdentifierRegistry::protocolRequestId()
                                                    "request-PID_A.3"
                                                    "request-PID_B.3"  (no collision)
                                                          │
                                                          ▼
                                              Inspector Frontend NetworkManager
                                              (single merged resource list)

Significance

Site Isolation이 도입한 process 경계를 잇기 위해 새로 추가된 IPC 및 ID 생성 영역입니다. Inspector 경로는 원래도 privileged하면서 복잡한 영역이었는데, 이제는 하나의 process가 아니라 sandbox로 격리된 여러 renderer process를 가로지르게 되었습니다.

Audit directions

좁게 보면, frontend에 노출되는 문자열 ID가 process 식별자를 inspector 표면으로 유출하는지, 그리고 침해된 renderer가 보내는 조작되거나 비정상적인 FrameIdentifier/ResourceLoaderIdentifier 값이 UIProcess 측 aggregation을 혼란시킬 만한 충돌이나 spoofing된 ID를 만들어낼 수 있는지 점검할 필요가 있습니다. 인자 1개짜리 protocolFrameId() overload는 FrameIdentifier의 상위 32비트를 bit-shift하여 process ID를 복원하는데, diff 자체에서 이 방식이 provisional frame에 대해서는 부정확하다고 명시하고 있습니다(webkit.org/b/310164). 알려진 바와 같이 부정확한 이 fallback 경로가 attacker가 영향을 미칠 수 있는 식별자로 도달 가능한지 확인할 가치가 있습니다. 범위를 넓혀 보면, UIProcess에 새로 추가된 ProcessQualified<ResourceLoaderIdentifier> deserialization 경로는 renderer가 제공한 식별자를 신뢰하여 trust boundary를 넘어 inspector 상태를 라우팅합니다. 따라서 UIProcess 측 registry에 도달하는 다른 ProcessQualified<> deserializer들도 같은 신뢰 가정을 두고 있는지 함께 점검해야 합니다. 패턴을 찾을 때는, renderer가 값을 직접 선택할 수 있는 key로 색인된 UIProcess 측 map이면서, key에 포함된 PID 외에는 connection별 namespace 분리가 없는 구조인지를 확인하십시오.

---