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.
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.
> 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.
That essentially means frame-src is set to that same thing since it’s not specified. So the bypass in the example would still work since it’s iframing the same (trusted) domain even if they explicitly specify frame-src.