[cap-talk] Security considerations for cookies

[Mark Seaborn]

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?

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?

AFAIK, TLS client certs aren't very usable, but then I've never set one up.
Would I be right in thinking that TLS client certs get sent to any server
that requests a cert, as with SSH public keys?  This would make them a more
broadly-scoped form of ambient authority than cookies and HTTP auth.


> 7.2.  Ambient Authority
>
>   If a server uses cookies to authenticate users, a server might suffer
>   security vulnerabilities because user agents occasionally issue HTTP
>   requests on behalf of remote parties (e.g., because of HTTP redirects
>   or HTML forms).


Not sure if you're looking for feedback on the wording, but this reads as
somewhat vague.  How about: "A server that uses cookies to authenticate
users can suffer from security vulnerabilities because user agents provide
mechanisms that allow one party to issue HTTP requests on behalf of
another.  These mechanisms include HTTP redirects and HTML forms."


  When issuing those requests, user agent attaches
>   cookies even if the entity does not know the contents of the cookies,
>   possibly letting the remote entity exercise authority at an unwary
>   server.
>


>   User agents can mitigate this issue to some degree by
>   providing APIs for suppressing the Cookie header on outgoing
>   requests.
>

You're referring to UMP here?


>   Although this security concern goes by a number of names (e.g.,
>   cross-site scripting and cross-site request forgery),


Cross-site scripting is caused by failure to escape strings, not by cookies.


>   the issue stems
>   from cookies being a form of ambient authority.  Cookies encourage
>   server operators to separate designation (in the form of URLs) from
>   authorization (in the form of cookies).  Disentangling designation
>   and authorization can cause the server and its clients to become
>   confused deputies and undertake undesirable actions.
>

Again, I'm not sure how much depth you want to go into, but you could define
(or refer to definitions of) ambient authority and confused deputies.


>   Instead of using cookies for authorization, server operators might
>   wish to consider entangling designation and authorization by treating
>   URLs as object-capabilities.


I think "object-capability" is reserved for references that are unforgeable
(OS and language caps), not merely unguessable, but I'm not sure of the
exact definitions people have settled on.

7.3.  Clear Text
>
>   The information in the Set-Cookie and Cookie headers is transmitted
>   in the clear.
>

Not if they're sent over HTTPS.

  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.


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?

For example, the Web Geolocation API says that the browser should display
the requester's origin when prompting the user, where "origin" is defined by
HTML 5 to include the port number.  Firefox 3.5 apparently violates this by
not displaying the port number.  I am sure this is of no consequence for
most users, for whom port numbers are not meaningful.  This property of
cookies seems like another reason not to care -- at least for sites that use
cookies.

  For this reason,
>   servers SHOULD NOT both run mutually distrusting services on
>   different ports of the same machine and use cookies to store
>   security-sensitive information.
>

It's OK to do it on the same machine (i.e. IP address) if different domain
names are used, I think.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100212/ff3a709b/attachment-0001.html