CSP isn't respected when a WebAssembly worker loads a script from a sandboxed iframe

[lifofifoX]

This is primarily an issue on /preview.

You can reproduce this locally with inscription c60d52c61de64b24b193ec317481fbb6114b7ca61b44fa582dd51dc344559f3bi0 on preview page. But it works as expected under /content.

I had to make the following change to make it work. My understanding is that it's ok to add allow-same-origin here as the CSP headers will still be respected, but I'm not 100% sure. So, wondering if you have any ideas.

diff --git a/src/templates/iframe.rs b/src/templates/iframe.rs
index 42abadb..592b7a1 100644
--- a/src/templates/iframe.rs
+++ b/src/templates/iframe.rs
@@ -29,7 +29,7 @@ impl Display for Iframe {
 
     write!(
       f,
-      "<iframe sandbox=allow-scripts scrolling=no loading=lazy src=/preview/{}></iframe>",
+      "<iframe sandbox='allow-scripts allow-same-origin' scrolling=no loading=lazy src=/preview/{}></iframe>",
       self.inscription_id
     )?;

[casey]

Can you describe what the issue is? Is it that you're able to make a request outside of the CSP sandbox, or you can't make one which should be permitted?

[lifofifoX]

Can you describe what the issue is? Is it that you're able to make a request outside of the CSP sandbox, or you can't make one which should be permitted?

Can't make one which should be permitted.

For example, inscription d1560d8b7487ab854ea9bb1fc2bb4eb3d11e5bd3f02881bee6d11958b8998329i0 loads a WASM module, which then tries to load /content/3891327c4bbefc8f0683c51338504d1bfdcc850c5bd8d16c6b34b6f400a8f214i0 but fails with this error:

Security Error: Content at moz-nullprincipal:{1a22a952-4ae6-425c-936e-cd9ad2a763bc}?http://0.0.0.0:4200 may not load data from http://0.0.0.0:4200/content/3891327c4bbefc8f0683c51338504d1bfdcc850c5bd8d16c6b34b6f400a8f214i0. 

[elocremarc]

According to mozilla docs you can't have allow-scripts and allow-same-origin in the same sandbox because the iframe can break out of the sandbox. I went down this rabbit hole pre recursion when I wrote this proposal up about adding allow-same-origin.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#sandbox

[lifofifoX]

@elocremarc Yeah. Need to figure out if that's still the case when CSP headers are present.

[thinginab]

I could be wrong, but I think this case I added might have the same cause - /preview isn't in the initial CSP header but /content is, which I think means the resulting iframe is blocked when created from a document loaded from /preview but not when same document loaded from /content.

https://github.com/ordinals/ord/issues/3362