[cap-talk] Security considerations for cookies

[Mark Seaborn]

On Sat, Feb 13, 2010 at 5:49 AM, Adam Barth <cap-talk at adambarth.com> wrote:

> On Fri, Feb 12, 2010 at 6:13 AM, Mark Seaborn <mseaborn at chromium.org>
> wrote:
> > On Thu, Feb 11, 2010 at 3:39 PM, Adam Barth <cap-talk at adambarth.com>
> wrote:
> >>   For servers that do use cookies for security, servers SHOULD use a
> >>   redundant form of authentication, such as HTTP authentication or TLS
> >>   client certificates.
> >
> > Don't these both introduce ambient authority as well?
>
> 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.


 > Why use redundant authentication?  If I log in with a password to get a
> > cookie, why should I log in with a password via HTTP authentication as
> well?
>
> 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?  Wouldn't this only work if the
client is not using HTTPS exclusively to connect to the server?  (Maybe this
is clearer from the rest of your document -- is it online somewhere?)

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


>>   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.


>>   Servers SHOULD encrypt and sign their cookies.
> >
> > It sounds like you're saying that servers should encrypt cookies-at-rest
> --
> > those stored in a database.  Otherwise I am not sure if you're saying:
> >  * cookies should only be sent over an encrypted channel, or
> >  * cookies should consist of encrypted data.
>
> 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".
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.)

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?

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


 >> 7.4.  Weak Confidentiality
> >>
> >>   Cookies do not provide isolation by port.  If a cookie is readable by
> >>   a service running on one port, the cookie is also readable by a
> >>   service running on another port of the same server.  If a cookie is
> >>   writable by a service on one port, the cookie is also writable by a
> >>   service running on another port of the same server.
> >
> > I didn't know that.  I suppose this ties in with your "Beware of
> > Finer-Grained Origins" paper.  Does this mean that there is little point
> in
> > considering origins to be <scheme, domain, port> tuples instead of being
> > synonymous with domain names?
>
> 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.

Cheers,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100213/8c82042d/attachment.html