RE: fyi: Strict Transport Security specification

forwarding on bechalf of AndyS..

From: Steingruebl, Andy <asteingruebl@paypal.com>
Sent: Saturday, September 19, 2009 8:25 AM
To: Jonas Sicking; =JeffH
Cc: public-webapps@w3.org; Hodges, Jeff; Adam Barth; Collin Jackson
Subject: 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 Saturday, 19 September 2009 23:42:14 UTC