[cap-talk] Security considerations for cookies

[David Wagner]

Adam Barth  wrote:
>I think it depends on what you think the goals of the Security
>Considerations section are.  My understand is that it serves two
>purposes:
>
>1) It's CYA for the IETF.  If something goes wrong, the IETF doesn't
>want to be blamed.  They want to point to the security considerations
>and say "look, we told you that wasn't a good idea."
>
>2) It's a resource for folks who want to use the protocol securely.
>By listing all the things we know are wrong with the protocol and
>recommending mitigations, folks can use that information to build more
>secure systems.
>
>Purpose (1) pushes us to be as ridiculous and draconian as possible.
>The more we tighten down the recommendations, the better CYA we get.
>However, purpose (2) pushes us to recommend things that folks might
>actually want to implement.

My goals: Help people use the protocol securely.  Yes, I'd like to
recommend things that folks might actually want to implement.  Listing
things that can go wrong (a blacklist of antipatterns to avoid) is fine as
far as it goes, but that's not always the best way to help developers;
sometimes it might be helpful to also give positive recommendations
(some positive patterns to follow).

Aren't CYA considerations are a dubious basis for making these kinds of
technical recommendations?  Can't the CYA goal can be met in other ways,
without compromising the quality of the technical advice?

>Returning to the issue at hand, I don't think that everyone is going
>to switch to using cookies exclusively as hash keys.  For example,
>ASP.NET exports all its server-side state to the client in an
>encrypted-and-MACed cookie.  They do this to avoid having to keep
>per-user state on the server, making ASP.NET services scale better.

I can't speak to performance or scalability, but when it comes
to security, replay attacks are a non-obvious hazard with ASP.NET's
ViewState mechanism (just as you'd predict for any encrypt-and-MAC
approach to secure management of cookies):
  http://seclists.org/bugtraq/2005/May/27
  http://scottonwriting.net/sowblog/posts/3747.aspx
Note the bottom line advice from the latter post: it's tempting for
developers to think that since ViewState is encrypted and signed, it's
safe; but that is mistaken; and the author of MS's documentation on
ViewState recommends "don't trust view state" (even if it was signed
and encrypted).

I'm not sure about the full scope within which ViewStates can be replayed,
and explaining this to a programmer sounds non-trivial.  If I'm reading
Microsoft's documentation correctly, ViewState is bound to the page
but not to the session, and it's not bound to the username unless the
programmer takes a special step to set ViewStateUserKey.  See also:
  http://scottonwriting.net/sowblog/posts/3747.aspx
It sounds like by default ViewStates can be replayed from session to
session, or from user to user, or to an instance of the same page but
with different query parameters.  But Microsoft's documentation fails
to explain this hazard in an understandable way:
  http://msdn.microsoft.com/en-us/library/ms972976.aspx

>I'd rather recommend that all cookies be encrypted and MACed so that
>folks build that into frameworks rather than trying to draw fine
>distinctions between which things can be stored "in the clear."

I too think it would be good if frameworks supported secure use of this
kind of state.  Are you suggesting that if the framework is providing
this support, then encrypt-and-MAC is better than unguessable IDs?
I don't see why.  Can you spell out the argument?

A framework could support storing state with unguessable IDs in the same
way it supports session management.  Actually, for some common usage
cases, there is no need to "wish for" new features from the framework:
in cases where developers want to use session cookies, they can just
store the data in the Session object.

Perhaps the new functionality you are asking for (from frameworks) is
support for state stored in persistent cookies.  I'm not sure whether
it will be easier to support persistent state generically in frameworks
using unguessable IDs or easier with encrypt-and-MAC.  With unguessable
ID approach, there's probably some integration with the database needed.
With encrypt-and-MAC, there's probably some key management (particularly
for clustering or load balancing).

For non-persistent state, a framework that uses unguessable IDs might
be provide a safer API than a framework that uses encrypt-and-MAC.
The natural API for non-persistent state (analogous to that for Session
state) becomes immune to replay attacks the framework implements it using
unguessable IDs, but I don't immediately see how to implement such an API
securely using plain encrypt-and-MAC (without enabling replay attacks).

In any case, if you decide to recommend encrypt-and-MAC, then I think
it would be useful to warn about replay attacks.

Another possibility is to mention both approaches and the considerations
for each.

By the way, I had no intention to draw fine distinctions between which
things can be stored in the clear.  Instead my intent was to describe
one fairly simple pattern that is reasonably secure.