Re: Session Fixation Vulnerability in Web-based Applications

From: Steve Midgley (steve.midgley@MIXRUN.COM)
Date: 12/19/02

  • Next message: Russ: "Revised: Microsoft Security Bulletin - MS02-070" 
    Date:         Thu, 19 Dec 2002 11:06:58 -0800
From: Steve Midgley <steve.midgley@MIXRUN.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

    Regarding this paper [ http://www.acros.si/papers/session_fixation.pdf
    ], I have thought off and on about this kind of problem as a software
    systems designer. I believe there are some fairly easy remedies to this
    problem that don't require changes to DNS/Web server systems.

    First off, thanks to Mitja Kolsek for bringing this issue into the
    daylight.

    I'd like to share my thinking on this subject and how to avoid this and
    related vulnerabilities. I hope it is helpful. Feedback welcome.

    Short version (repeated in long version):

    Do not allow http session cookies to inform the validity of
    authentication mechanisms. Issue a new cookie at the time secure login
    and use that to check the security credentials of a user. (cf. 5.2 in
    ACROS' paper).

    ACROS covered the "defense through design" issue in their paper, but I
    felt that it didn't go deeply enough to allow a programmer to easily
    build a methodology to solve this problem. Hopefully my long version
    below will do that.

    Long version:

    One work around to the problem of an attacker fixing another users
    session, without modifying the way servers generate session ID's is as
    follows:

    Think of the http server generated sessions as "UI Sessions" and as
    incidental to securing the website. Within this session (either client
    or server-side) you can store details such as font/color/screen size
    and all the other peculiarities that need to be tracked but that have
    no impact on authentication. When a user comes to your site, they are
    unauthenticated, but you can still remember who they are from a "UI
    Session" perspective and set up all these details for them (i.e. User
    friendly).

    When the user wants to log-in/authenticate themselves, you can use this
    "UI Session" to seed the username on the login screen, if appropriate,
    but they still need to enter the password (of course).

    The main issue here is that while the user login is taking place (after
    the user presses "login" button but before the next page is returned),
    the middleware software system (e.g. php or asp) should issue a *new*
    "authentication key" for this domain (usually in the form of a new
    cookie for the client). The contents of this key could be a GUID
    (encrypted or not). On the server-side the middleware should construct
    a "authentication package" which indicates which user logged in, what
    their authority profile is like, date of login, etc. The client key
    merely serves to access this authentication package, when is demanded
    by appropriate server subsystems.

    The server and client now each hold mutual authentication tokens that
    can be compared against each other (the key on the client side and the
    package on the server side). From this time on, whenever an
    authenticated activity is undertaken, the server should check the
    client's "authentication key/cookie" which was generated during logon.
    (I believe that this method is similar to the way security is handled
    on many client/server network OS.)

    The important detail here is that the *server* holds the information as
    to which user is represented by a client "authentication key" for a
    given authenticated session. So while an attacker could grant access to
    her own account for a user (not useful), it is impossible to fix an
    authenticated session in advance, and have that session be subsequently
    "logged in" to a new user account.

    By distinguishing between "auto-generated" http session keys from
    webservers and middleware-generated authentication keys, I believe it
    is possible (and easy) to design systems that are not vulnerable to
    session fixation attacks. (Only by allowing authentication information
    to "ride" on http sessions does the fixation vulnerability become
    acute.)

    In short: Do not allow http session cookies to inform the validity of
    authentication mechanisms. Issue a new cookie upon secure login and use
    that to check the security credentials of a user.

    Getting access to the "authentication cookie" by other means and using
    it is still a serious problem, but I'm not holding my breath for
    browsers to become substantially more airtight than they currently are.
    (Writing your authenticated system in pure Java might provide some
    extra security in this regard since you would then have to hack the
    Java client-data subsystem not just IE cookies to get usable
    authentication keys).

    At least that's my analysis of the issue. Again thanks to ACROS for
    highlighting this long-standing vulnerability. Hopefully web system
    engineers out there will take heed.

    Best regards,

    Steve Midgley

    oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
    Delivery co-sponsored by TruSecure Corporation
    oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
    Demonstrate your knowledge and understanding of core IT Security, become
    TICSA certified.

    Are you responsible for IT security in job function, but not necessarily
    in title? Do you want to prove your IT security knowledge and increase
    opportunities? Interested? Visit;

    http://www.trusecure.com/solutions/certifications/ticsa/

    for more information.
    oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo