- From: Sigbjørn Vik <sigbjorn@opera.com>
- Date: Thu, 13 Feb 2014 09:51:18 +0100
- 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 anyhow 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