locked
Session/Authentication not removed server-side after logout RRS feed

  • Question

  • User1577272293 posted

    By doing a security review I noticed that authentication (.ASXP) and Session (ASP.NET_SessionID) were removed from the client using a standard set-cookie header. But, if those headers are suppressed, the session and authentication still work, this is, neither the authentication state or session were removed on the server side.

    This means there is no effective way to close a session as maybe the user's browser will "forget" the cookie, but anyone able to sniff the content can still have an active session on the system. I see it kind of a "reverse session fixation" or "dangerous persistent sessions".

    So I tried to find a way to remove the session on the server and none of the following (or a combination of them) works (Although content is cleared, the session itself remains active):

    Request.Cookies.Remove ("ASP.NET_SessionID")

    Request.Cookies["ASP.NET_SessionID"]=null;

    Request.Cookies["ASP.NET_SessionID"].Expires = DateTimeNow.AddDays(-1);

    Session.Abandon();

    Regenerating the session using SessionIdManager

    How can then session and authentication state be "deleted" from the server, so if a browser resends the same id in a cookie, this is not recognized and thus considered invalid?.

    Wednesday, May 21, 2014 3:49 PM

Answers

  • User-1949460947 posted

    Yes, both the authentication and the session management has some vulnerabilities in ASP.NET:

    The authentication does not have a "session" on the server, so if a valid auth cookie is received by the server the authentication is considered to be successfully completed. The auth cookie has an expire date, and the cookie contains a token which also has an expiration date. Both date must be valid otherwise the server will reject the auth cookie. So if someone steals the auth cookie (which is very difficult on the wire if you use SSL), the expiration date of the token in the cookie determines how long she can use it.

    To prevent this kind of attack, you can manually embed some additional information about the client into the token.

    The Session is also vulnerable, because the SessionStateModule does not check whether a session already exists for a given session ID. An attacker can send a session cookie with any syntactially valid session ID to the server, and the server will spin up a brand new Session.

    To prevent this attack you can create a HttpModule which acts before the SessionStateModule on the pipeline and performs additional validation.

    If you want to ensure that all information is stored about the user's session on the server, you can use the Session.Clear or Session.RemoveAll methods.

    Hope this helps,

    - György

    p.s. Shameless plug: I wrote more about these vulnerabilities and workarounds in the Ethical hacking ASP.NET chapter of this book: http://www.amazon.com/Real-World-NET-Silverlight-Indispensible/dp/1118021967

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, May 21, 2014 4:47 PM