User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36 Steps to reproduce: 1. Go to csptester.io 2. Enter CSP header "img-src http:" and HTML code "<img src="https://www.eff.org/sites/all/themes/frontier/images/logo_full.png">" 3. Hit submit Actual results: The image renders and no violations are reported. Expected results: The image is blocked and an img-src csp violation is reported. This works as expected in Firefox stable.

This regressed on Nightly between 20150712 and 20150713. Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=eab21ec484bb&tochange=38d03bf4616e Regression from bug 1139297?

(In reply to Sebastian H. [:aryx][:archaeopteryx] from comment #1) > This regressed on Nightly between 20150712 and 20150713. > Pushlog: > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=eab21ec484bb&tochange=38d03bf4616e > > Regression from bug 1139297? You are right, that's definitely due to the change within Bug 1139297, see [1]. Given that there is a sniffy algorithm out there which abuses that behavior (see Bug 1218778) I am not sure if we indeed want to fix that. If you look at [2 and inlined underneath], the spec says that 'scheme-less' sources should be allowed to load over https if the policy specifies http. In my opinion it makes sense to extend that thinking and also allow https: loads if the policy is 'img-src http:'. I am open for discussions though. [1] http://hg.mozilla.org/mozilla-central/diff/9a1ab22d6d95/dom/security/nsCSPUtils.cpp [2] http://www.w3.org/TR/CSP2/#match-source-expression > If the source expression does not have a scheme, return does not match if any of the following are true: > the scheme of the protected resource’s URL is a case insensitive match for HTTP, > and url-scheme is not a case insensitive match for either HTTP or HTTPS > the scheme of the protected resource’s URL is not a case insensitive match for HTTP, > and url-scheme is not a case insensitive match for the scheme of the protected resource’s URL.

We should implement the CSP spec here, but this might be worth an update to the spec in order to clarify that even if a "*-src" directive specifies "http:", the browser should still follow redirects even if they go to "https:" URLs. Maybe the CSP spec provision that ckerschb linked to does this, but W3C specs are so opaque to me that I can't tell. As I said on the Sniffly bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1218778#c6), if a site is willing to load "http:" images, then it's willing to take whatever the network provides it. So there's no more risk in the browser accepting redirects from the network than in accepting the content from the network in the first place.

(In reply to Richard Barnes [:rbarnes] from comment #3) > We should implement the CSP spec here, but this might be worth an update to > the spec in order to clarify that even if a "*-src" directive specifies > "http:", the browser should still follow redirects even if they go to > "https:" URLs. Maybe the CSP spec provision that ckerschb linked to does > this, but W3C specs are so opaque to me that I can't tell. Currently, the CSP spec doesn't specify that, but I filed a new github issue [1] and it seems Mike West feels the same way we do. [1] https://github.com/w3c/webappsec-csp/issues/25

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #4) > (In reply to Richard Barnes [:rbarnes] from comment #3) > > We should implement the CSP spec here, but this might be worth an update to > > the spec in order to clarify that even if a "*-src" directive specifies > > "http:", the browser should still follow redirects even if they go to > > "https:" URLs. Maybe the CSP spec provision that ckerschb linked to does > > this, but W3C specs are so opaque to me that I can't tell. > > Currently, the CSP spec doesn't specify that, but I filed a new github issue > [1] and it seems Mike West feels the same way we do. > > [1] https://github.com/w3c/webappsec-csp/issues/25 Please note that our implementation was adopted by the CSP spec, see: https://w3c.github.io/webappsec-csp/published/FPWD-2015-01.html#match-url-to-source-expression Closing this bug as INVALID.