[cap-talk] Security considerations for cookies

[Adam Barth]

On Sat, Feb 13, 2010 at 11:47 AM, Mark Seaborn <mseaborn at chromium.org> wrote:
> On Sat, Feb 13, 2010 at 5:49 AM, Adam Barth <cap-talk at adambarth.com> wrote:
>> Yes.  Is there something specific you think would be better to
>> recommend?  In general, I wanted to point to things with RFCs in the
>> "general recommendations" section.
>
> Couldn't you recommend web-keys?  Although I don't think there is an RFC for
> web-keys.

I think it's better to be slightly general here.  We're writing the
document for the long term.  Web-keys are one instance of the general
concept, but they might seem archaic to a reader ten years from now if
some other URL capability scheme catches on.

>> HTTP authentication has the virtue of better integrity protection than
>> cookies.  For example, there isn't a way (that I know of) for an
>> active network attacker to force your HTTP auth credentials (at least
>> over HTTPS), but there is a way to overwrite your cookies.
>
> Are you saying there is a way for an active network attacker to overwrite
> your cookies, even if you're using HTTPS?

Yes.  An active network attacker can spoof an (unencrypted) HTTP
response from the server and include a Set-Cookie header.  Nothing in
the protocol stops that from overwriting cookies set over HTTPS.

> Wouldn't this only work if the
> client is not using HTTPS exclusively to connect to the server?

If the UA issues a single HTTP request, an active network attacker can
spoof an HTTP redirect response and cause the UA to generate an HTTP
request to the server.  Now, if the user agent is configured to use
Strict-Transport-Security for that host, there is some hope.  :)

> (Maybe this is clearer from the rest of your document -- is it online somewhere?)

I'm not sure what the best resource for this fact is.  I'm hoping
these security considerations with bring these sorts of issues to
light.

> Are there any consequences of overwriting a cookie other than denial of
> service?

Oh yes.  Some of the worse consequences involve login CSRF like
attacks.  For more background, please see:

http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf

Essentially, by overwriting the user's cookies with the attacker's
cookies, the attacker causes the user to communicate with the server
as if the user was the attacker.  If the user communicates
confidential information to the server (such as composing an email),
that information will likely be stored in the attacker's account.  For
example, the attacker can look the "drafts" or "sent email" folder and
read the user's confidential email.

Web-keys have the same login CSRF problems because the attacker can
force the user's browser to navigate to the attacker's web-key.  Now,
the user might not notice that they're interacting with the server
under the attacker's authority.

>> >>   User agents can mitigate this issue to some degree by
>> >>   providing APIs for suppressing the Cookie header on outgoing
>> >>   requests.
>
> I thought "to some degree" was a bit vague.  Providing an API like UMP only
> mitigates the issue if web apps use it.  The issue is not so much that user
> agents must be able to omit the cookie, but that servers must disregard the
> presence or absence of cookies.

That's the exact argument I've been making in the CORS/UMP discussion
in W3C WebApps, but MarkM and Tyler don't appear to agree with that
point of view.  Do you have a proposal for what we could say at that
point the draft that would be less vague?

>> I've changed this to the following:
>>
>> [[
>> Servers SHOULD encrypt and sign their cookies when transmitting
>> them to the user agent (even when sending the cookies over a secure
>> channel).
>> ]]
>
> It would be better to say that cookies should consist of encrypted/signed
> data, or "servers should use cookies that are encrypted and signed".

This text seems to be the same as the above, but in the passive voice.

> Referring to 'encrypting a cookie' is not literally accurate because the
> piece of data you're encrypting is not a cookie -- it is never sent in
> cookie context.  (I hope this is not too pedantic.  I did find the original
> wording ambiguous.)

I've changed this text to:

[[
Servers SHOULD encrypt and sign the contents of cookies
]]

> BTW, it is not clear why cookies should be encrypted even when sending over
> HTTPS.  Does this come back to my earlier question about overwriting
> cookies?

For example, the cookies are written to disk, where they might be
visible to others.  Also, the cookies could become visible during a
cross-site scripting attack.

> Presumably if a server uses Swiss numbers for its cookies, there is no need
> for the cookies to be encrypted and signed.

I presume you mean <http://wiki.erights.org/wiki/Swiss_number>?
Indeed, these do not require encryption or signatures.  However, it
can't hurt.  :)

This text is meant to encourage encryption and signatures at the
framework level, irrespective of the semantics of the cookies.  For
example, I believe ASP.NET encrypts and signs all cookies for good
measure.

>> Well, the isolation by scheme is super important.  Without that, HTTPS
>> wouldn't provide any protection from active network attackers.
>
> Is this because, if you're visiting https://a.com and http://b.com, an
> attacker could spoof content from http://b.com to frame spoofed content from
> http://a.com?  I think I see what you were referring to above.

Yes.  I'd recommend thinking about the issue slightly more abstract
(i.e., without referring to frames), but you seem to understand why
isolation is important.

The easier way to think about it is that an active network attacker
gets to inhabit / control every security context that trusts
information received over HTTP.  If a document from
https://example.com/foo.html shares a security context with
http://example.com/bar.html, then the active network attacker gets to
inhabit / control foo.html.

Adam