Re: [http-state] Security considerations overview

[Maciej Stachowiak <[e-mail]>]

On Mar 2, 2010, at 4:04 PM, David Morris wrote:

>
>
> On Tue, 2 Mar 2010, Adam Barth wrote:
>>
>> The issue is quite simple:
>>
>> 1) In an HTTPS response, the example.com server responds with
>> "Set-Cookie: foo=bar".  By default (i.e., without the optional Secure
>> attribute), this cookie does not have the secure-only-flag set.
>> 2) The user agent makes a single HTTP request.
>
> That case was excluded by my earlier restriction to all HTTP.

That kind of "all HTTP" restriction, at the UA level rather than the  
site level, is one that you can not count on in a browser or even in  
most kinds of site-specific UAs.


>> 3) The network attacker spoofs an HTTP response that contains an HTTP
>> redirect to http://example.com/.
>
> Only applies if there is an HTTP server on the same host. And it  
> requires
> a vulnerable infrastructure at either end of the connection.

Nope, you can spoof HTTP responses without the need for the targetHTTP  
server to really exist. All it requires is some vulnerable  
infrastructure somewhere.

>
> This also suggests some issues with HTTP redirect which have not been
> discussed in my reading/listening. It potentially exposes more than
> cookies to the sniffer of traffic.

HTTP traffic, since it is sent in the clear, obviously provides  
neither confidentiality nor integrity. What is non-obvious is that  
cookies by default make some of this built-in vulnerability leak over  
to affect HTTPS.

Regards,
Maciej