8
votes

I have an asp.net web form. when a user authenticate, it create a Secured cookie called .aspxauth

uppon logout, I call these 2 methods

FormsAuthentication.SignOut(); 
Session.Abandon()

Problem is that we had penetration test and if I steal the cookie, logout and manually reinsert the cookie, I become loggued in again. So the .aspauth isn't invalidated server side.

I've googled it and I can't find the answer to that security breach.

4
You can not de-activate it. Session.Abandon() will remove it from your user not from browser/client. - Avijit
ok so there is no solution to this cookie replay bug? I don't want to change the whole code to switch to membership class. - Yannick Richard
I mean, there must be a way to tell the server that a session token is now invalid?!! - Yannick Richard
I assume that this issue hasn't been resolved yet? And the any way of doing that is to invalid the sessionID? There is nice article about it How to secure your ASP.NET Azure Web App - krypru

4 Answers

4
votes

Microsoft has acknowledged this issue here: https://support.microsoft.com/en-us/kb/900111

They offer several ideas for mitigating this vulnerability:

  1. protect the application by using SSL
  2. Enforce TTL and absolute expiration
  3. Use HttpOnly cookies and forms authentication in ASP.NET 2.0
  4. Use the Membership class in ASP.NET 2.0

Regarding the last one, I'll paste the contents from the site for convenience/preservation:

When you implement forms authentication in ASP.NET 2.0, you have the option of storing user information in a Membership provider. This option is a new feature that is introduced in ASP.NET 2.0. The MembershipUser object contains specific users.

If the user is logged in, you can store this information in the Comment property of the MembershipUser object. If you use this property, you can develop a mechanism to reduce cookie replay issues in ASP.NET 2.0. This mechanism would follow these steps:

  1. You create an HttpModule that hooks the PostAuthenticateRequest event.
  2. If a FormsIdentity object is in the HttpContext.User property, the FormsAuthenticationModule class recognizes the forms authentication ticket as valid.
  3. Then, the custom HttpModule class obtains a reference to the MembershipUser instance that is associated with the authenticated user. You examine the Comment property to determine whether the user is currently logged in.

Important: You must store information in the Comment property that indicates when the user explicitly signed out. Also, you must clear the information that is in the Comment property when the customer eventually signs in again.

If the user is not currently logged in as indicated by the Comment property, you must take the following actions:

  1. Clear the cookie.
  2. Set the Response.Status property to 401.
  3. Make a call to the Response.End method that will implicitly redirect the request to the logon page.

By using this method, the forms authentication cookie will only be accepted if the user has not been explicitly signed out and the forms authentication ticket has not yet expired.

3
votes
0
votes

This remains an issue in .NET Framework. Everyone seems to think Session.Abandon() is the answer, but the sad truth is that command does not invalidate the session on the server's side. Anyone with the right token value can still resurrect a dead session, until the session expires based on the Web.config settings (default = 20minutes).

A similar questioner posed this question a long time ago here: Session Fixation in ASP.NET

Most of those links are dead, and Microsoft has no new news on the topic. https://forums.asp.net/t/2154458.aspx?Preventing+Cookie+Replay+Attacks+MS+support+article+is+now+a+dead+link

Worse still, you're still vulnerable to this cookie replay attack even if you're implementing a completely stateless MVC application and don't use the Session object to store data between views. You can even turn off session state in the web.config settings and still replay cookies to gain access to a logged-out session.

The true solution is hack-y and described here, and you need to have session data enabled InProc to use it.

  • When the user logs in, set a boolean value in the session data, like Session["LoggedIn"] = true;, which is stored on the server side.
  • When the user logs out, set that value to false.
  • Check the session value on every request--an attacker trying to replay a session isn't going to be nice to you and come in through the Login page only. It's probably easiest to do this using a custom filter and registering it globally in the global.asax file (so you don't have to duplicate the code everywhere, or attribute every controller/method).

Even if the attacker has all the cookie values, they won't be able to re-use that same session ID, and the server will automatically delete it once it reaches the specified timeout.

-2
votes
if you are using the FormsAuthentication, you can use this code. By using this code you can destroy the created cookies by setting the Expire property of HttpCookie. It will help you:
FormsAuthentication.SignOut();
Session.Clear();
Session.Abandon();
Session.RemoveAll();
// clear authentication cookie
HttpCookie httpCookie = new HttpCookie(FormsAuthentication.FormsCookieName, "");
httpCookie.Expires = DateTime.Now.AddYears(-1);
Response.Cookies.Add(httpCookie);