Three origin-validation procedures for untrusted IPC values

Component: WebKit IPC | aba0fcd

WebKit의 multi-process 구조에서 WebContent process는 sandbox 안에서 동작하며 공격자가 도달할 수 있는 renderer입니다. 반면 UI process는 더 높은 권한을 갖기 때문에, renderer가 IPC를 통해 주장하는 origin 값을 그대로 신뢰해서는 안 됩니다. IPC::Untrusted<T> wrapper는 바로 이 원칙을 코드 차원에서 강제하기 위해 존재합니다. 다만 어떤 검증이 정확한 검증인지는 UI process가 실제로 추적하고 있는 ground truth에 달려 있고, 그 ground truth는 configuration에 따라 달라집니다.

이번 commit은 Untrusted<T> 값에서 신뢰할 수 있는 origin을 복원하는 세 가지 검증 primitive를 도입했습니다. FirstPartyAuthority, TopLevelFirstPartyAuthority, CommittedClientOriginAuthority가 그것입니다. 여기에 더해, 호출하는 쪽이 사용하게 될 EXTRACT_WITH_MESSAGE_CHECK 매크로의 형태도 함께 문서화되었습니다. 다만 아직 이들을 호출하는 코드는 없습니다. 실제 message handler에 연결하는 작업은 뒤로 미뤄졌으므로, 동작상의 변화는 없습니다.

Significance

FirstPartyAuthority는 site isolation이 비활성화되어 있거나 web process가 하나뿐인 경우, site 검사 자체를 완전히 꺼버립니다. 해당 configuration에서는 이 검사가 필요로 하는 ground truth가 아예 존재하지 않기 때문입니다. site isolation이 없는 환경에서는 하나의 WebContent process가 페이지와 그 페이지가 embed한 모든 cross-site iframe을 함께 담당할 수 있습니다. 이때 임의로 주장된 origin을 해당 process에 기록된 main-frame site와 비교해봐야, subframe origin에 대해서는 의미 있는 답을 얻을 수 없습니다. 반면 TopLevelFirstPartyAuthority와 CommittedClientOriginAuthority는 구조상 해당 process 자신의 top-level origin이나 committed origin임이 보장된 값에만 적용됩니다. 그래서 이런 예외 처리가 필요하지 않습니다.

Audit directions

앞으로 눈여겨볼 패턴은, 검증 강도가 runtime configuration에 따라 달라지는 validator입니다. Narrow: 후속 commit들이 이 primitive를 handler에 연결해 나가는 과정에서, 호출 지점마다 확인할 점은 하나입니다. 선택된 validator의 ground truth가 검사 대상이 되는 값을 실제로 포괄하는지 여부입니다. site isolation이 꺼진 빌드에서 subframe origin을 FirstPartyAuthority로 검증한다면, 스스로 검사를 비활성화한 함수에 검증을 맡기는 셈입니다. Wider: 세 procedure는 작은 어휘 집합을 이루고 있고, 그 사이의 불일치가 앞으로 가장 나오기 쉬운 오류 유형입니다. 더 강한 validator를 사용하는 호출 지점이라면, 그 값이 정말로 해당 process 자신의 top-level origin이나 committed origin인지 하나씩 점검할 필요가 있습니다. Widest: configuration에 따라 우회가 성립하는 검증 계층이라면, 약한 configuration에서는 대신 무엇에 의존하고 있는지에 대한 명시적인 답이 있어야 합니다. 코드 리뷰 관점에서 보면, 자기 검사를 건너뛰는 분기를 품은 validator에는 그 skip을 안전하게 만들어주는 성질이 무엇인지 밝히는 주석이 붙어야 합니다.