Re: Remove paths from CSP?

On 12-Feb-14 13:31, Mike West wrote:
> On Wed, Feb 12, 2014 at 12:59 PM, Sigbjørn Vik <
> <>> wrote:
> The goal of CSP's reporting functionality is to give site authors detail
> about attacks occurring on their sites. "Hey, author, I blocked script
> from executing right here on your page. Maybe you should go look at your
> escaping code again, because someone injected something!" It's unlikely
> that an attacker will cooperate with the attackee by delivering their
> payload with CORS headers in order to enable reporting.

Well, right there is a problem. If a page author can tell if a
redirected-to third party resource fits a regexp or not, he can tell
redirection chains of that third party resources. This is opening up a
new hole in the same domain policy.

> An issue is that leakage is inherent in the functionality: it isn't
> possible to block an image from loading, for example, without making the
> fact that the image was blocked visible to the page that loaded it.

That should be fairly easy. Even if blocked, call onload, and return the
image dimensions to the page. That is all a page can detect anyway.

> If CSP is to be at all valuable in blocking content injection attacks, the
> act of blocking will by necessity leak the fact that a resource was blocked.

If CSP is to be at all valuable, it needs to avoid opening new security
holes, not trade one security hole for another. Especially not if the
former is avoidable by good web site security practices, while the
latter is not.

> I'd welcome proposals that would avoid this.

Block disallowed resources from interacting with the page, but pretend
to the page that they were loaded.

Sigbjørn Vik
Opera Software

Received on Wednesday, 12 February 2014 13:03:26 UTC