WebAuthn related-origin requests

Component: WebKit WebAuthn | 86e9570

WebAuthn은 원칙적으로 호출한 origin의 registrable domain이 relying party(RP) ID와 정확히 일치할 것을 요구합니다. 한 사이트가 다른 사이트를 대상으로 하는 credential을 발급하거나 assertion을 수행하지 못하도록 막는 장치입니다. "related origin requests" 확장은 이 조건을 완화합니다. RP가 well-known 경로에 관련 origin 목록을 JSON으로 게시해 두면, 브라우저는 origin이 일치하지 않는 요청을 받아들이기 전에 그 목록을 가져와 검증합니다.

이번 commit이 그 동작을 구현했습니다. 페이지의 origin이 요청 대상 RP ID와 일치하지 않으면, WebKit은 UIProcess에서 RP의 well-known JSON 리소스를 가져옵니다. 이 fetch에는 크기, timeout, redirect 정책, MIME type 제한이 걸려 있습니다. 이후 호출한 origin이 반환된 목록에 포함되어 있는지 확인하고, 없으면 SecurityError로 거부합니다. 구현으로는 WellKnownOriginList(WebCore, 파싱과 매칭을 담당하는 free function), 그리고 WellKnownResourceFetcher와 RelatedOriginsValidation(WebKit, fetch와 검증을 잇는 glue 코드)이 추가되었습니다. 여기에 검증된 related origin을 embedding app으로 전달하는 새 WKUIDelegatePrivate SPI(...relatedOrigins:completionHandler:)와 33개의 unit test, 15개의 API test가 함께 포함되었습니다.

Significance

이제 WebKit은 credential의 scope를 정하는 신뢰 결정을 네트워크에서 받아온 데이터에 근거해 내립니다. 그 데이터는 RP 자신이 반환한 JSON 응답이며, RP ID의 호스트에 응답하는 서버가 무엇이든 그 서버가 좌우하는 redirect chain을 거쳐 전달됩니다. fetch 대상과 응답 본문, redirect chain은 모두 WebKit이 통제하지 못하는 영역입니다. 결국 fetch에 걸린 제한과 origin 매칭 로직의 정확성만이, 신뢰할 수 없는 origin을 인가된 것으로 취급하는 상황을 막아 주는 경계선에 해당합니다.

Audit directions

앞으로 눈여겨볼 패턴은 네트워크로 가져온 문서를 근거로 보안 결정을 내리는 경우입니다. 이때 fetch에 걸린 제한은 parser의 정확성만큼이나 무거운 역할을 맡게 됩니다. 출발점은 WellKnownOriginList의 파싱·매칭 함수입니다. canonical 형태에 대한 정확한 문자열 비교가 아닌 origin 비교는, 아슬아슬하게 빗나가는 우회 사례를 오랫동안 만들어 왔습니다. 그에 못지않게 중요하지만 놓치기 쉬운 지점은 WellKnownResourceFetcher의 redirect 정책입니다. RP가 통제하지 않는 호스트로 redirect가 넘어가는 순간, "RP가 이 목록을 게시했다"는 전제가 "다른 누군가가 게시했다"로 바뀌기 때문입니다. 같은 구조는 WebKit이 무언가를 인가하기 위해 well-known 리소스를 가져오는 모든 지점에서 반복됩니다. 다른 well-known fetcher들도 redirect와 MIME 처리가 이번 구현만큼 엄격한지 점검해 볼 만합니다.

---