[12] [WebCore] Re-validate same-origin after CSP sandbox application in view transitions

Severity: High | Component: WebCore View Transitions | cc6b337

Rated High because the diff adds a second origin check at Document::reveal() time so the view-transition pipeline does not consume captured snapshots when the new document's effective origin became opaque due to CSP sandbox; pre-fix, captured ImageBuffers and element names from the outgoing document leaked into a sandbox-opaque document.

Document::reveal re-validates same-origin between the source document's origin and the new document's post-CSP securityOrigin() before installing ViewTransitionParams.

Source/WebCore/dom/Document.cpp

+    if (!isSameOriginAfterCSP(sourceOrigin, securityOrigin()))
+        return;
     installViewTransitionParams(WTFMove(params));

TOCTOU between URL-origin-based admission and post-CSP final origin: cross-document view transition snapshots installed into a CSP sandbox opaque-origin document.

Patch Details

Document::reveal adds a final same-origin check using the post-CSP securityOrigin(). The admission gate at navigation start (URL-derived origin) is unchanged.

Background

Cross-document view transitions snapshot element images and geometry from an outgoing document and replay them in the incoming document. The pipeline is gated on same-origin between the documents. Per the HTML spec, Content-Security-Policy: sandbox without allow-same-origin replaces the document's effective origin with an opaque origin after CSP processing.

Analysis

The pre-fix pipeline performed its same-origin check once, at navigation initiation in DocumentLoader::navigationCanTriggerCrossDocumentViewTransition — using the URL-derived origin of the response. CSP processing runs after this; by the time resolveInboundCrossDocumentViewTransition ran during Document::reveal(), securityOrigin() was opaque, but the pipeline never re-validated.

Aaa Aaaaa Aaaaaaaaa Aaaaaaaa Aaaaaa Aaaaaaaaaaaaaaaaaaaaaaaa Aaaaaaaaaaaaaaa Aaaaaaaaaaaaaaaaaaaaaaaaaaa Aaaaaaaaaaaaaaaaaa Aaa Aaaaaaaa Aaaaaaaaaaaaa Aaaaaaaaa Aaaa Aaa Aaaaaaaa Aaaa Aa Aaaa Aaaa a Aaaaaaaa Aaaaa Aaa Aaa Aaaaaaaaaa Aaaa Aa Aaaaaaa Aa a Aaaaaaa Aaaaaa Aaaaaaa Aaa Aaaaaaa Aaaaaaaaa Aa Aaaaaaaaaaaa Aaaaa Aaa Aaaaaaaaaaaaaaaa Aaaaa

Aaaa Aaaaaaa Aaa Aaaaaaaaaaa Aaaaaaaaa Aa Aaaa Aaaaaaaaaa Aaaaaaaa Aaaaaaaa Aaaaaaaaaaaa Aa Aaa Aaaaaaaa Aa Aaa Aaaaaaaa

🔒

Explores how a single response header can silently retarget which document inherits sensitive captured state, and how the loading pipeline's check-once design enabled this trust-boundary slip.

Subscribe to read more

Audit directions

a Aaaaaaa Aaaaaaaaa Aaaaa Aaaa Aaaaaaa Aaaaaa Aaaa Aaa Aaa Aaaaaa Aaaaaaaaaaa Aaaaaaaaaaaaaa Aaaaaaaa a Aaaaaaaaaaaaaaa Aaaaa Aa Aaaaaaaa Aa Aaaaa Aaaaaaaa Aaaaaaaaa Aaaaaaa Aaaaaaaaaaaaa Aaaaaaa Aaaaaaaaaaaaaaaaaa Aa Aaaaaaaaa
a Aaaaaaaaaaaaaaaaaaaaaaaa Aaaaaaaaaaaa Aaaaa Aaaa Aaaa Aaaaa Aaa Aaaaaa Aaaaaa Aaaaa Aaaaaaa Aaaaaa Aaaaaaa Aaa Aaaa Aaaaaa Aa Aaa Aaaaaaaaaaaa Aaaaaa
a Aaaaaaa Aaaa Aaaa Aaaaaaaa Aaaa Aaaaaaa Aaaaaaaaaaaaaa Aaaaaaa Aaaaaaaaa Aaaaaaaaaaaaaaaaaaa Aaaaaaa Aaaaaaaaaaa Aaaaaaaaaaa Aaa Aaa Aaaa Aaaaaaa

🔒

Four reusable audit patterns identified for trust-boundary checks that race response-header processing, with concrete entry points across the WebCore navigation pipeline.

Subscribe to read more