[cap-talk] Security considerations for cookies
cap-talk at adambarth.com
Thu Feb 11 15:39:04 PST 2010
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.
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.
redundant form of authentication, such as HTTP authentication or TLS
7.2. Ambient Authority
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
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
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
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
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
More information about the cap-talk