I don't think you're reading my question properly - I'm asking about when frame-src IS specified - but just in case it's me that's missing something. I'll reword my question.
In the example they have default-src set to ‘self’ ‘unsafe-inline’
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.
i don't understand. If they set frame-src to an explicit list of domains they trust surely default-src becomes irrelevant and the exploit doesn't work? I'm testing it now and creating an iframe won't work.
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.
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.