[cap-talk] Security considerations for cookies

[Adam Barth]

Thanks.  I cheated and got input from Mark Miller before emailing this list.  :)

Adam


On Fri, Feb 12, 2010 at 2:01 AM, Toby Murray
<toby.murray at comlab.ox.ac.uk> wrote:
> Dear Adam,
>
> Your section on ambient authority is an excellent summary, as no doubt
> you intended it to be, of much of the philosophy shared by many on
> this list. Thanks for taking the time to distil it out so clearly.
>
> Others on this list with more web savvy can probably give more useful
> feedback on specifics so I'll leave it to them.
>
> Cheers
>
> Toby
>
> On 11 February 2010 23:39, Adam Barth <cap-talk at adambarth.com> wrote:
>> People of cap-talk,
>>
>> As some of you know, I'm working on a specification for how cookie
>> work in practice.  As part of writing the spec, I'd like to add a
>> section on the security perils of using cookies.  I was hoping that
>> this group could give me some feedback on what I have so far.
>>
>> Thanks,
>> Adam
>>
>>
>> 7.  Security Considerations
>>
>> 7.1.  General Recommendations
>>
>>   The cookie protocol is NOT RECOMMENDED for new applications.
>>
>>   For applications that do use the cookie protocol, servers SHOULD NOT
>>   rely upon cookies for security.
>>
>>   For servers that do use cookies for security, servers SHOULD use a
>>   redundant form of authentication, such as HTTP authentication or TLS
>>   client certificates.
>>
>> 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).  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.
>>
>>   Although this security concern goes by a number of names (e.g.,
>>   cross-site scripting and cross-site request forgery), 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.
>>
>>   Instead of using cookies for authorization, server operators might
>>   wish to consider entangling designation and authorization by treating
>>   URLs as object-capabilities.  Instead of storing secrets in cookies,
>>   this approach stores secrets in URLs, requiring the remote entity to
>>   supply the secret itself.  ALthough this approach is not a panacea,
>>   judicious use of these principles can lead to more robust security.
>>
>> 7.3.  Clear Text
>>
>>   The information in the Set-Cookie and Cookie headers is transmitted
>>   in the clear.
>>
>>   1.  All sensitive information conveyed in these headers is exposed to
>>       an eavesdropper.
>>
>>   2.  A malicious intermediary could alter the headers as they travel
>>       in either direction, with unpredictable results.
>>
>>   3.  A malicious client could alter the Cookie header before
>>       transmission, with unpredictable results.
>>
>>   Servers SHOULD encrypt and sign their cookies.  However, encrypting
>>   and signing cookies does not prevent an attacker from transplanting a
>>   cookie from one user agent to another.
>>
>>   In addition to encrypting and signing the contents of every cookie,
>>   servers that require a higher level of security SHOULD use the cookie
>>   protocol only over a secure channel.
>>
>> 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.  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.
>>
>>   Cookies do not provide isolation by scheme.  Although most commonly
>>   used with the http and https schemes, the cookies for a given host
>>   are also available to other schemes, such as ftp and gopher.  This
>>   lack of isolation is most easily seen when a user agent retrieves a
>>   URI with a gopher scheme via HTTP, but the lack of isolation by
>>   scheme is also apparent via non-HTTP APIs that permit access to
>>   cookies, such as HTML's document.cookie API.
>>
>> 7.5.  Weak Integrity
>>
>>   Cookies do not provide integrity guarantees for sibling domains (and
>>   their subdomains).  For example, consider foo.example.com and
>>   bar.example.com.  The foo.example.com server can set a cookie with a
>>   Domain attribute of ".example.com", and the user agent will include
>>   that cookie in HTTP requests to bar.example.com.  In the worst case,
>>   bar.example.com will be unable to distinguish this cookie from a
>>   cookie it set itself.  The foo.example.com server might be able to
>>   leverage this ability to mount an attack against bar.example.com.
>>
>>   Similarly, an active network attacker can inject cookies into the
>>   Cookie header sent to https://example.com/ by impersonating a
>>   response from http://example.com/ and injecting a Set-Cookie header.
>>   The HTTPS server at example.com will be unable to distinguish these
>>   cookies from cookies that it set itself in an HTTPS response.  An
>>   active network attacker might be able to leverage this ability to
>>   mount an attack against example.com even if example.com uses HTTPS
>>   exclusively.
>>
>>   Servers can partially mitigate these attacks by encrypting and
>>   signing their cookies.  However, using cryptography does not mitigate
>>   the issue completely because an attacker can replay a cookie he or
>>   she received from the authentic example.com server in the user's
>>   session, with unpredictable results.
>>
>> 7.6.  Reliance on DNS
>>
>>   The cookie protocol relies upon the Domain Name System (DNS) for
>>   security.  If the DNS is partially or fully compromised, the cookie
>>   protocol might fail to provide the security properties required by
>>   applications.
>> _______________________________________________
>> cap-talk mailing list
>> cap-talk at mail.eros-os.org
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>