RE: fyi: Strict Transport Security specification

> -----Original Message-----
> From: public-webapps-request@w3.org
[mailto:public-webapps-request@w3.org] On Behalf Of Jonas Sicking
> Sent: Friday, September 18, 2009 10:30 PM
> To: =JeffH
> Cc: public-webapps@w3.org; Hodges, Jeff; Adam Barth; Collin Jackson
> Subject: Re: fyi: Strict Transport Security specification


> This definitely looks very interesting. I am admittedly a bit worried
> about requests to one url to a server affecting any subsequent
> requests to not just that server, but also to any subdomain.

> I wonder for example if the client when receiving a
> Strict-Transport-Security header should make a request to the root url
> of the same origin to verify that the server indeed wants to opt in to
> STS.

I think what you're pointing out is that our notion of Origin, and the
ability in the usual web programming model for regular user-applications
to have full access to the HTTP layer is security problematic in certain
deployment scenarios.  

I don't think that your solution is really workable and/or solves the
problem at hand. Because / and /stuff.html and /~user/cgi-bin/web.cgi
are all part of the same Origin, they already can muck with the whole
security model anyway.    If a website doesn't wish to have this content
muck around with the overall security policies then they are already in
serious danger by allowing people to control the HTTP layer from this
other content.  

This "sub-content" can already:
  - Set the Secure or HTTPonly flag on cookies in possible contradiction
of the policy of "/"
  - Read and write all cookies for the domain
 
If a site wants to prevent this sort of behavior it needs to either:

  1. Filter certain HTTP data from making it to certain content running
within it. For example, put in a filter
     that doesn't pass cookies on to certain URIs.
  2. Filter outbound data coming from certain URIs to prevent them from
setting certain data.

If a site doesn't want to give control over STS policy to all of its
content, then it can choose to implement the second of these two
policies. If it doesn't, it is still open to all manner of other
attacks.  Collin and Adam already documented most/all of this in their
paper "Beware of Finer-Grained Origins" -
http://w2spconf.com/2008/papers/s2p1.pdf

--
Andy Steingruebl

Received on Sunday, 20 September 2009 15:34:30 UTC