Bug 236624 - Document.write into iframe with CSP sometimes blocks resources loads in inner iframe
Summary: Document.write into iframe with CSP sometimes blocks resources loads in inner...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: Safari 15
Hardware: Unspecified macOS 12
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-02-14 17:23 PST by Matt Bierner
Modified: 2022-02-23 13:58 PST (History)
6 users (show)

See Also:


Attachments
Simple repo with two html files (1.33 KB, application/zip)
2022-02-14 17:23 PST, Matt Bierner
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Bierner 2022-02-14 17:23:43 PST
Created attachment 451967 [details]
Simple repo with two html files

== Steps to reproduce the problem ==

1. On a page with a restrictive content security policy 
2. Embed a sandboxed, same origin iframe
3. On the parent page, use `setInterval` to check the ready state of the iframe. Once it is listed as `complete`, try using `document.write` to write a new html document into it. This new html document should have its own CSP and try to load content that would be allowed by that CSP but blocked by the parent page's

I've attached two simple html files that show this issue in action. To reproduce, start a simple local server in the folder and open `index.html`


== What is the expected behavior? == 
The new content of the inner iframe should load (it should load a picture of a cat with a red background)


== What went wrong? ==
Occasionally resources in the inner iframe will be blocked due to a CSP violation. This happens maybe 25% of the time for me. I can reproduce it even more reliably by reducing the `setInterval` timeout

The fact that the code sometimes works suggests to me that there is some sort of race.


== Does this work in other browsers? ==
This is also broken in Chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=1297377). I can't test in Firefox because the entire scenario is blocked by https://bugzilla.mozilla.org/show_bug.cgi?id=1754872

== Other notes==
This example seems contrived, but is used in the VS Code codebase to work around https://bugs.webkit.org/show_bug.cgi?id=33604
Comment 1 Radar WebKit Bug Importer 2022-02-14 19:57:02 PST
<rdar://problem/88943548>
Comment 2 Matt Bierner 2022-02-23 13:58:50 PST
Over on Chrome, we determined this is likely by-design (although quite confusing): https://bugs.chromium.org/p/chromium/issues/detail?id=1297377

The issue with the polling here is that the iframe document may still be on `about:blank` when the ready state is first checked. This results in the new content written into the document inheriting the parent page's CSP instead of providing its own

To fix this, I added a check to our code to make sure we are checking the ready state of the expected page instead of `about:blank`