Re: [http-state] Security considerations overview

[Tyler Close <[e-mail]>]

On Tue, Mar 2, 2010 at 4:11 PM, Maciej Stachowiak <[e-mail]> wrote:
>
> On Mar 2, 2010, at 3:39 PM, 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.
>> 3) The network attacker spoofs an HTTP response that contains an HTTP
>> redirect to http://example.com/.
>> 4) The user agent follows the redirect and sends the cookie foo in the
>> clear, where it can be observed by the attacker.
>
> Sounds like attacker can violate the integrity, as well as confidentiality,
> of non-Secure cookies this way (i.e. they could spoof the non-SSL response
> and set the cookie to the value of their choice.)
>
> Can this type of attack also affect the integrity of Secure cookies, or is
> there something to prevent them from being overwritten from non-SSL?

According to section 4.1.2, the cookie store *only* takes into account
the cookie-name, domain-value, and path-value when overwriting a
cookie. So an active network attacker could overwrite a "Secure"
cookie by specifying a Set-Cookie: header in a forged plain HTTP
response. As Adam indicated, if the user-agent makes a plain HTTP
request to *any* domain, the active network attacker can turn that
request into a request to the victim domain by forging a redirect
response. The malicious Set-Cookie header is specified in response to
the redirected request.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html