How to kill .ASPXAUTH cookie at server end?

Question

I am NOT a developer but a penetration tester. While doing a pentest on a website based on .NET framework I reported a 'Improper Session Management' issue.The user was getting authenticated using .ASPXAUTH cookie. What happens is when the user logs out, the .ASPXAUTH cookie value is set to blank in the client browser. But if you use the same .ASPXAUTH ,put it in browser manually and refresh the page user directly gets authenticated.

I recommended the developers that the .ASPXAUTH cookie should get destroyed at server end as soon as the user logs out. But they suggested that the cookie and session related stuff is entirely managed by framework and there is no way it can be killed at server end.

So is there any way to kill the .ASPXAUTH at server end?

Thank You in Advance

Answer 1

So is there any way to kill the .ASPXAUTH at server end?

No, there's no way to do that because ASP.NET FormsAuthentication is not related with any state on the server. That's one of its weak points. What you could do is relate this cookie with a session state that will be persisted on the server. This way in order to be authenticated it won't be enough to have a valid forms authentication cookie but in addition to that it should relate to some state on the server which could be invalidated any time you want (for example when logging out). In this case after the user has signed out from the website, he will not be able to use the .ASPXAUTH cookie anymore assuming he has captured its value while he was authenticated.

Answer 2

To expand a bit on Darin's answer, the Web Forms Cookie auth is stateless. Your client is correct in stating that the framework does a lot of "magic" under the covers. That's not to say that the client can't do something about it, though.

By default, the Forms Auth cookie is stateless. It includes some kind of identifier (username, user id, that's up to the developer), and that's about it. There are many properties you can set on the cookie (is it a session cookie, how long is it good for, etc) but that doesn't affect how the contents of the cookie is treated. The cookie's contents are then encrypted and MACed by the machine key so they cannot be tampered with, but that doesn't prevent them from being portable or replayable.

The client can continue to use Forms Authentication if they want, they just need to step back a bit from all of the magic.

I presume under the covers they are doing something like FormsAuthentication.SetAuthCookie. Instead, they can create a FormsAuthenticationTicket which allows including user supplied data. This data can be something that's tied to a session (not necessarily, HTTP session). Then use FormsAuthentication.Encrypt to encrypt the ticket, and it gives back a cookie which can be set on an successful authentication response.

When a page loads (or better yet in Global.asax's Application_AuthorizeRequest) they can grab the cookie from the request, call FormsAuthentication.Decrypt to decrypt the authentication cookie, and check that the user data matches the session.

When the user explicitly signs out, clear the session from that user so it doesn't match the cookie anymore. Then the checking of the user data should reject the cookie and force them to acquire a new one.