[cap-talk] Security considerations for cookies
cap-talk at adambarth.com
Fri Feb 12 21:49:42 PST 2010
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:
>> 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.
> 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.
The way I would imagine this working is that you'd login via HTTP
auth, which would then set a cookie (e.g., a session cookie).
> 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.
That might or might not be how browsers work today, but there's
nothing inherent in the design of TLS client certs that forces this to
be the case. I suspect we'll see some more innovation in client certs
to make them easier to use and to have better privacy properties.
>> 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).
> Not sure if you're looking for feedback on the wording, but this reads as
> 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."
I've adopted a variant of the text you propose:
security vulnerabilities because some user agents let remote parties
issue HTTP requests from the user agent (e.g., via HTTP redirects and
>> User agents can mitigate this issue to some degree by
>> providing APIs for suppressing the Cookie header on outgoing
> You're referring to UMP here?
Yes, UMP is an example of such an API. The point is more general
though. For example, you might want a content security policy that
blocks all outgoing cookies. For example, the "no-outgoing-cookies"
directive I proposed 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.
Perhaps in the proximate, but (as Mark is fond of point out) you can
run untrusted script in your web page as long as that script can't
abuse ambient authority. Some of that authority comes from the
location bar at the top of the window, but much of it comes from
>> 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.
I'm not sure how to do non-normative citations in an RFC. I'll ask
around to see what the best way to do this is.
>> 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.
I'm happy to use whatever word is most accurate here.
>> 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.
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
>> 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. Also,
there's more to secure in the browser than just cookies. Cookies have
weaker protections than most browser privileges because they're old.
> 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
features. Port-based isolation isn't hugely valuable, but it's the
model we've got. There some value in not introducing gratuitous
complexity when designing new features. (Sadly, we're stuck with some
pretty complex old features.)
>> For this reason,
>> servers SHOULD NOT both run mutually distrusting services on
>> 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.
Good point. I've changed "machine" to "host".
Thanks for your detailed comments.
More information about the cap-talk