Re: Remove paths from CSP?

On Wed, Feb 12, 2014 at 12:59 PM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> That some major websites have bugs which can be found by a dedicated
>
attacker to tell e.g. logged-in status, is not an argument that we
> should build this bug into browsers by default, for easy exploitation,
> including against secure websites.
>

I think there is a misunderstanding here. The fact that major websites have
bugs which can leak logged-in status is not a justification for building
anything in, but a justification for removing functionality.


> If detailed error information is needed, and the third-party site is ok
> with passing this information on, then a header set by the third-party
> site could easily allow this.
>

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.


> If the underlying problem of cross domain leakage is fixed, then paths
> can be used without a problem.
>

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. 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.

I'd welcome proposals that would avoid this.

-mike