W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2014

Re: Remove paths from CSP?

From: Sigbjørn Vik <sigbjorn@opera.com>
Date: Thu, 13 Feb 2014 09:51:18 +0100
Message-ID: <52FC8786.2080809@opera.com>
To: Pete Freitag <pete@foundeo.com>
CC: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Odin Hørthe Omdal <odinho@opera.com>, Adam Barth <w3c@adambarth.com>, Dan Veditz <dveditz@mozilla.com>, Brad Hill <bhill@paypal-inc.com>, Michal Zalewski <lcamtuf@google.com>, Garrett Robinson <grobinson@mozilla.com>
On 12-Feb-14 17:18, Pete Freitag wrote:
> On Wed, Feb 12, 2014 at 8:02 AM, Sigbjørn Vik <sigbjorn@opera.com
> <mailto:sigbjorn@opera.com>> wrote:
>     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.
> An issue to consider with this approach is a CSRF attack vector. For
> example if I have Content-Security-Policy: img-src 'images.example.com
> <http://images.example.com>'; and the attacker injects the following:
> <img
> src="https://api.example.com/perform/some/csrf-vulerable/action/delete/all/things"
> />
> CSP would have prevented it, but if you load blocked resources the CSRF
> attack would still be successful.

We have a few possible scenarios:
a) The page which contains the CSP header is attacker controlled. The
attacker would not want to block the target, so CSP would not help
against CSRF.
b) The target does not contain a referrer check, so may be attacked from
anywhere, including an attacker controlled page. CSP would not help
against CSRF.

So let us assume that the target contains a referrer check, and the
attacker must inject contents into another page in order to exploit it.
In that case CSP has already failed to stop this content injection, but
let us continue anyhow:
c) The page with the injected content is meant to be able to submit to
the target, i.e. the target is not blocked with CSP. CSP would not help
against CSRF.
d) The page with the injected content is not meant to be able to submit
to the target, i.e. the target is blocked with CSP. The target
whitelists the page with the injected content through the referrer
header anyhow.

So only d) is exploitable. In this case the website has already
performed the following mistakes:
a) No CSRF token protection
b) Referrer protection only on the target
c) Referrer protection and CSP protection do not match
d) Actively using CSP, but failing to protect against injected content

If you consider d) to be a major concern (I don't), then it is easily
fixable by not sending cookies with the request.

Sigbjørn Vik
Opera Software
Received on Thursday, 13 February 2014 08:51:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:37 UTC