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.
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):
- Prevent Logon to chosen sessions
- Prevent Attackers from obtaining valid session ID (if possible)
- 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
- MS Connect Denied Bug Submission on Session Fixation - https://connect.microsoft.com/feedback/viewfeedback.aspx?FeedbackID=143361&wa=wsignin1.0&siteid=210
- 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
