Document-Isolation-Policy infrastructure

Component: WebCore security policy | 6164d9c

LayoutTests/ipc/blob-registry-null-url-crash.html

LayoutTests/TestExpectations

COEP require-corp가 설정되면 cross-origin no-cors subresource는 로드가 차단됩니다. 예외는 해당 resource가 Cross-Origin-Resource-Policy로 명시적으로 허용한 경우뿐입니다. 문제는 이 검사가 서로 독립된 여러 지점에서 각각 수행된다는 점입니다. 한편 Document-Isolation-Policy(DIP)는 이를 대체하기 위해 새로 등장한 메커니즘입니다. frame tree 전체가 협조하지 않아도 단일 document에 별도의 agent cluster와 process를 부여하는 방식이라, site isolation이 전제되어야 합니다.

이번 commit에서는 Document-Isolation-Policy header를 parsing해 PolicyContainer에 저장하도록 변경되었습니다. 이 값은 초기 about:blank, about:srcdoc, data:, javascript:, blob: document에 상속되며, history에서 복원될 때도 함께 복구됩니다. 이때 isolate-and-require-corp 값이 설정되면 NetworkLoadChecker, memory cache, service worker response, Cache API에서 CORP가 강제됩니다. 다만 policy가 적용되려면 secure context여야 하고, site isolation과 DocumentIsolationPolicyEnabled가 모두 활성화되어 있어야 합니다. Agent cluster keying은 아직 구현되지 않았습니다.

Significance

WebKit에 두 번째 cross-origin isolation 메커니즘의 첫 단계가 도입되었습니다. 결과적으로 서로 독립된 여러 load path에서 일관되게 강제되어야 하는 policy field가 하나 더 늘어난 셈입니다.

Audit directions

버그가 나올 가능성이 가장 높은 곳은 enforcement 지점 사이의 틈입니다. 먼저 CORP를 검사하는 각 지점(NetworkLoadChecker, memory cache, service worker response, Cache API/DOMCache, BackgroundFetchRegistration)에서 DIP 검사를 건너뛰는 경로가 있는지 살펴볼 필요가 있습니다. redirect, opaque response나 range response, 그리고 policy 적용 이전에 cache된 response가 대표적인 후보입니다. 또한 PolicyContainer 상속과 history 복원 과정에서 저장된 policy와 실제 적용되는 policy가 어긋나는 지점이 없는지 확인해야 합니다. Network process가 새 IPC field를 그대로 신뢰하지 않고 검증하는지도 점검 대상입니다. 한편 shared worker와 service worker에는 policy가 없으므로, 이를 경유해 cross-origin resource를 얻을 수 있는 경로가 있는지 확인이 필요합니다. 마지막으로 site isolation, secure context 요건, preference 중 하나라도 꺼져 있을 때 policy가 부분적으로만 적용되지 않는지 점검해야 합니다. 이와 함께 document가 policy를 선언하고 있지만 실제로는 완전히 강제되지 않는 상태에서 어떻게 동작하는지도 살펴볼 만합니다.