W3C home > Mailing lists > Public > public-web-security@w3.org > June 2011

Re: CSP: non-TLS scheme restrictions must allow TLS-enabled schemes automatically

From: Gervase Markham <gerv@mozilla.org>
Date: Mon, 27 Jun 2011 09:14:19 +0100
Message-ID: <4E083BDB.5040403@mozilla.org>
To: Brian Smith <bsmith@mozilla.com>
CC: public-web-security@w3.org
On 26/06/11 22:19, Brian Smith wrote:
> In the draft spec, there is the statement "If a scheme is not
> specified as part of the source expression, a user-agent must use the
> same scheme as the protected document." I think additionally, there
> should be a statement that says "A source that has a non-TLS scheme
> (e.g. 'http' instead of 'https') and that uses the default port for
> the scheme (e.g. 80 for http) implies an additional source with the
> TLS variant of the scheme on that scheme's default port (e.g. 'https'
> on port 443)." Or, something a little more comprehensible than that.

Isn't there a risk here? HTTP vhosting exists, but TLS vhosting does not
(really) yet. So the owner of the website which is at
http://www.foo.com/ might find that accessing https://www.foo.com/
actually gives them the HTML content of https://www.bar.com/, which is
hosted on the same machine, but controlled by someone else entirely.

So if the owner of bar.com found an XSS hole in foo.com, they could
inject links to "https://www.foo.com/", which would be CSP-allowed, and
yet would return content under his control. (Albeit with certificate
mismatch errors.)

Is this risk basically just theoretical, or worth considering?

Received on Monday, 27 June 2011 08:14:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:19 UTC