[cap-talk] Security considerations for cookies

[Adam Barth]

Thanks for your feedback.  I've added the following text:

[[
        However, encrypting and signing cookie
        contents does not prevent an attacker from transplanting a cookie from
        one user agent to another or from replying the cookie at a later
        time.
]]

and

[[
      <section anchor="session-identifiers" title="Session Identifiers">
        <t>Instead of storing session information directly in a cookie (where
        it might be exposed to or replayed by an attacker), servers commonly
        store a nonce (or "session identifier") in a cookie. When the server
        receives an HTTP request with a nonce, the server can look up state
        information associated with the cookie using the nonce as a key.</t>

        <t>Using session identifier cookies limits the damage an attacker can
        cause if the attacker learns the contents of a cookie because the
        nonce is useful only for interacting with the server (unlike non-nonce
        cookie content, which might itself be sensitive). Furthermore, using a
        single nonce prevents an attacker from "splicing" together cookie
        content from two interactions with the server, which could cause the
        server to behave unexpectedly.</t>

        <t>Using session identifiers is not without risk. For example, the
        server SHOULD take care to avoid "session fixation" vulnerabilities. A
        session fixation vulnerability proceeds in three steps. First, the
        attacker transplants a session identifier from his or her user agent
        to the victim's user agent. Second, the victim uses that session
        identifier to interact with the server, possibly imbuing the session
        identifier with the user's credentials or confidential information.
        Third, the attacker uses the session identifier to interact with
        server directly, possibly obtaining the user's authority or
        confidential information.</t>
      </section>
]]

Let me know if you have additional feedback.

Adam


On Tue, Feb 16, 2010 at 12:35 AM, David Wagner <daw at cs.berkeley.edu> wrote:
> 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.
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>