undefined | Better HN

0 pointsalxlu7y ago0 comments

Yeah if you set frame-src to something that doesn’t include the current domain then it should prevent loading an iframe from the same origin

That being said, this technique might still work in theory on whatever domains you have specified in frame-src if it doesn’t include ‘self’.

So if you’re foo.com and frame-src only allows bar.com. If you managed to get script into foo.com maybe you could put an iframe pointing to bar.com/reallylongorinvalid

That being said I haven’t had a chance to try this out on my machine yet so I could be missing something

Also it looks like their demo includes sandbox allow-same-origin and allow-scripts in its CSP.

0 comments

2 comments · 1 top-level

alxluOP7y ago· 1 in thread

Following up on this. It looks I spoke too soon about the separate domain iframe, since that would be blocked by the iframe's cross domain policy.

So if the domain you are currently on listed in frame-src it looks like you would be safe from this. But if you explicitly set frame-src to include either 'self' or the domain itself then you would still be vulnerable to this.

nailer7y ago

Thanks for replying. Yeah I get this / agree with you now.

> But if you explicitly set frame-src to include either 'self' or the domain itself then you would still be vulnerable to this.

Exactly.

- There is a site foo.com, which has a CSP, but allows iframes from self or foo.com

- A user is able to inject some XSS to open an iframe to foo.com/50x.html, an nginx page with no CSP. Since CSP allows our own site to be used in iframes, this is allowed.

- In that page, further JS is injected to extract secrets from the foo.com parent page and connect them to remote networks. Since foo.com/50x.html has no CSP, this is allowed.

j / k navigate · click thread line to collapse