W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2013

CSP interacting with HSTS

From: Ian Melven <imelven@mozilla.com>
Date: Mon, 14 Jan 2013 14:15:18 -0800 (PST)
To: public-webappsec <public-webappsec@w3.org>
Message-ID: <894773075.7143924.1358201718760.JavaMail.root@mozilla.com>


In https://bugzilla.mozilla.org/show_bug.cgi?id=826805 , Brian Smith brought
up a possible problematic interaction with CSP and HSTS :

"Because of HSTS, which can cause of to automatically redirect HTTP requests to HTTPS, we need to interpret a "http:" 
scheme-source as "http: https:", and we need to interpet a host-source of the form "http://host[:port]" as "http://host[:port] https://host:[port]".

Otherwise, if we get the CSP directive before the site turns on HSTS, and then later the site turns on HSTS, 
the site will break. In particular, consider the case where we've cached a page in the HTTP response cache with 
a CSP with scheme-sources of the form "http:", which references sub-resources (using http:// URLs) of a 
newly-HSTS-enabled site. Without this change, that page would be broken until it is evicted from the cache, 
because HSTS will rewrite the http:// URLs as https:// URLs, and then CSP will block the https:// content from loading."

regardless of caching, for example if http://a.com contains images from
http://b.com and has a CSP of image-src: http://b.com , if b.com turns on
HSTS, this will break. 

other places in Gecko explicitly handle this situation - I'm informed that websockets for example
will generally not follow a redirect without an implemented redirect header, EXCEPT in the case
where the redirect is to an identical URL with a wss: scheme instead of a ws: scheme. 

thoughts/comments welcome !

Received on Monday, 14 January 2013 22:15:46 UTC

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