AppSec Blog

Session Attacks and ASP.NET - Part 1

I've spent some time recently looking for updated information regarding session attacks as they apply to ASP.NET and am still not completely satisfied with how Microsoft has decided to implement session management in ASP.NET 2.0+ (haven't looked at 4.0 beta yet).

Before illustrating how a specific attack works with some specific countermeasures for ASP.NET (in Part 2), it's important to understand the Session and Authentication architectures in ASP.NET.

ASP.NET Session Architecture

Session state is setup and maintained through an HTTP Module. If the ASP.NET web.config file is setup to enable session stae, the this HTTP Module kicks into gear and the first time the web application uses the session object and the user doesn't already have a session, the ASP.NET Session module will drop a cookie on the client or do some URL rewriting to put the Session ID in the URL. All authentication and authorization mechanisms in ASP.NET are also handled through HTTP Modules (Windows, Forms, Passport). The figure below illustrates the ASP.NET HTTP pipeline functions - a request is processed by every installed module and finally processed by a handler.

httpmodule

ASP.NET HTTP Pipeline - HTTP Modules and Handlers

What's interesting about this architecture is that the session management and the authentication modules are completely decoupled and have no awareness of each other. This allows Sessions to function with or without any type of authentication - functionally, this can be useful. However, from a security perspective (depending on what you're trying to accomplish) this can be somewhat of a problem.

So, for example, consider next Forms Authentication. If enabled,it uses a completely different cookie than the session cookie (or different URL parameters if using cookieless). Likewise, with Windows Authentication (integrated), Client Certificates, or Basic Authentication - even though there is no need for the second cookie, it still is decoupled from the authentication mechanism and will function completely independent of each other.

So before moving on, the take-away point about ASP.NET is this - ASP.NET Session is decoupled from any type of authentication. They are completely unaware of each other.

Next let's look at a specific session attack...

Session Fixation

Session Fixation is a specific attack against the session that allows an attacker to gain access to a victim's session. The attack starts with the attacker visiting the targeted web site and establishing a valid session ? a session is normally established in one of two ways - when the application delivers a cookie containing the Session ID or when a user is given a URL containing the Session ID (normally for cookieless). In this step, the attacker has fixed, or locked in, a known good session.

The attacker, having fixated on this session, will then entice/trick the victim into using this Session ID. At this point the attacker and victim share the same Session ID. Now anytime the information stored in this fixated session is used to either make decisions for the victim or display information only the victim should see - these can be potentially used and/or viewed by the attacker.

This does imply that the victim must do something to affect session before the attacker can take advantage of them. For example, if a flag is stored in session that is used to indicates if a user is authenticated as well as the database key used to extract information for that user ? then the attacker will wait for the victim to authenticate and then visit portions of the site they wouldn't normally be allowed to visit, seeing anything that the victim sees - as long as they have the same authorization level, since the decisions to allow access and view user information were controlled by information stored in session.

See http://www.acrossecurity.com/papers/session_fixation.pdf for a nice writeup on Session Fixation.

The Countermeasures to session fixation are as follows (as described in the paper above):

  1. Prevent Logon to chosen sessions
  2. Prevent Attackers from obtaining valid session ID (if possible)
  3. Restricting Session ID usage (prevention techniques that also apply for stolen/hijacked session ID's as well as session fixation)

Does ASP.NET Pass?

Does ASP.NET OUT OF THE BOX get a passing grade for protecting Session, considering the three countermeasures above? I'll address each countermeasure and how ASP.NET stacks up below.

Prevent Logon to chosen sessions:

Some attempt to use the regenerateExpiredSessionId property of the <sessionState> element in web.config in hopes it will help.

The MDSN documentation states:

"regenerateExpiredSessionId - Specifies whether the session ID will be reissued when an expired session ID is specified by the client. By default, session IDs are reissued only for the cookieless mode when regenerateExpiredSessionId is enabled. For more information, see IsCookieless. "

So this is only for EXPIRED (or non-existent) sessions, and old cookie expired Session ID's will be thrown out. So if the attacker retrieves a good session from the ASP.NET web application, and sends it to the victim - well, it's not expired yet (unless the victim doesn't fall for the attack in the allotted session timeout). This is a good thing, however, Session Fixation already requires an active session, not an expired one...so this particular attribute will not help.

Prevent Attackers from obtaining valid session ID (if possible):

SSL/TLS cannot be enforced in the web.config for Session ID delivery, this is only an option for the Forms Authentication cookie.

Restricting Session ID usage:

The ability to tie a session the authentication is not automatic - it requires custom code. Considering session management and authentication modules are out-of-the-box, ASP.NET could potentially couple them.

Comparing ASP.NET session management implementation to the recommended countermeasures for session fixation doesn't look so good...ASP.NET however, does mark the cookie HTTPOnly, which does helps prevent XSS attacks against the session on *most* of the latest browser versions - this certainly reduces risk, but it is not foolproof.

There have been bug submissions to MS asking for a bug fix for their session management implementation [1] and others asking that Microsoft fix the way ASP.NET handles sessions [2] to address issues described in this two part post. The recommendation to fix these issues aren't necessarily unreasonable; however, the way ASP.NET session management is implemented, 'fixing' the issues might not be so straightforward and might even be simply a side-effect of how session management was implemented and not necessarily just an oversight or vulnerability. The down-side of the chosen implementation is that developers need to be educated on this specific nuance of ASP.NET session management and know when and how to protect their web applications accordingly.

Next, Part 2 will explore specific attack vectors, countermeasures and some thoughts that will hopefully spur on some additional discussion.

References

[1] MS Connect Denied Bug Submission on Session Fixation
https://connect.microsoft.com/feedback/viewfeedback.aspx?FeedbackID=143361&wa=wsignin1.0&siteid=210

[2] Preventing Session Fixation through Session ID Regeneration in Java and ASP.NET
http://keepitlocked.net/archive/2007/12/27/preventing-session-fixation-through-session-id-regeneration-in-java-and-asp-net.aspx

8 Comments

Posted June 17, 2009 at 2:32 PM | Permalink | Reply

Mike W.

I might missed something here. But a simply way to prevent session hijacking is to issue a new cookie by the application once user is successfully authenticated.

Posted June 17, 2009 at 4:25 PM | Permalink | Reply

J.R.

While your point that the session cookie can't be set to use SSL/TSL within the config is true, it can fairly easily be set within the global.asax file. That isn't hard, knowing that you need to do it is more of the challenge..

Posted June 17, 2009 at 7:29 PM | Permalink | Reply

j.monty

MikeW & J.R ''" thanks for the comments ''" I completely agree. Those are some ways we do deal with this issue ''" and this is a very solvable problem within ASP.NET.
The only reason I bring up the issue, is not out of spite of ASP.NET ''" I love it ''" but because of the problems with developer education. Most will never realize that they actually need to add extra code to solve this problem so it will most likely go unaddressed.
Since ASP.NET is a framework that does focus much on improving the overall security ''" this is one area I see for improvement ''" there are most likely potential solutions that could be implemented within the ASP.NET framework that would help to solve this problem.
What do you think? Do you think session management should be tied to authentication? Would you prefer some configuration options that would couple authentication to session management?

Posted June 18, 2009 at 1:46 PM | Permalink | Reply

Jeff

Jason,
We generally just avoid Session altogether in favor of database storage based on authenticated user id's/tokens. It also makes sense to avoid it because it cannot be supported on farms (without workarounds that are easier to just implement yourself). Are the issues you mention specifically issues only with asp.net built-in Session objects, or is there a larger issue to consider here?

Posted June 18, 2009 at 2:36 PM | Permalink | Reply

Mike W.

@j.monty
As you were saying, there is a need to issue a session cookie WITHOUT user ever have to provide any credentials. Thinking google analytics. So in that sense, decoupling the session creation and authentication is the only way to do it. It also conforms to the idea of "separation of concerns". In the case, where a login is required to create a session, the key is, as your 2nd reference suggests, is to invalidate the session created before the user logged in. If ASP.NET does issue a second cookie after the user is logged in, then it would have serve that purpose, ASP.NET SHOULD insist to see the 2nd cookie before a user is allowed to access the protected pages. An attacker can NOT access the protected page with just ONE cookie. Are you saying ASP.NET is NOT doing that?

Posted June 18, 2009 at 7:59 PM | Permalink | Reply

j.monty

Mike W ''" you are correct. There are certain situations where there's little benefit to work hard to protect the session ID, like in your example.
In retrospect I probably should have mentioned the risk factors for different sorts of sites. E.g. Banking site, ecommerce site, vs. social site, etc.
You are close as to the protection the second cookie might offer, but not quite. The Forms auth cookie does serve strictly as an authentication cookie, but provides no session protection.
ASP.NET does not invalidate and reissue a session after you log in''(as my next post will explain). This means the attacker can log in using THEIR personal credentials and fixate on a session, (Windows or Forms auth, whatever) . Then wait for the victim to log in ''" at this point, both are logged in using their own credentials, but the attacker and victim are sharing the same session!

Posted June 18, 2009 at 8:27 PM | Permalink | Reply

j.monty

Jeff,
> Is there a larger issue here?
Definitely. Being able to choose a session ID for a victim to use, or discover another users' Session ID can be essentially the same as having their username and password.
Not using ASP.NET's session mechanisms just means you have to not only solve session hijacking/fixation issues, but also all the other session management issues yourself. I.e. Session ID keyspace and entropy (randomness) so that attackers can't predict or guess session ID's and find sessions. This means using strong crypto for generating session ID (e.g. Encrypted Forms Authentication Ticket or Crypto Random number generator with 128 bits random, ''non-zerod' data).
So the answer to if it's better to just use your own ''" well, it depends on what your doing and how your doing it. The principals are the same for HTTP/Web no matter what language you are using.

Posted September 3, 2009 at 6:59 AM | Permalink | Reply

Niek

Jason,
It seems to me that having a session id means absolutley nothing if the web application complies with the secure coding guidelines (which MS published years ago) that all data stored in the ASP.NET session should be considered public information, and should not be relied on for identification or authorization purposes.
Each request handling piece of code should check the identity again, and determine the validity of the request against the current, secured, server side private application state.

Post a Comment






Captcha


* Indicates a required field.