Session Fixation Vulnerability Detection in ASP.Net

Improper handlings of session variables in an ASP.NET website is considered to be a serious threat and opens various doors to malicious hackers. For instance, a session variable could be manipulated in such a way as to subvert a login authentication mechanism. However, this article illustrates a session fixation bug in a .NET website by providing various live scenarios that usually lead to a website being vulnerable in terms of session hijacking. Moreover, the article circulates detailed information about exploiting vulnerable websites as well as recommended practices for protecting them against session fixation attacks.

Session Fixation Internal

A session fixation attack allows spoofing another valid user and working on behalf of its credentials. It typically fixates on another person's session identifier to breach in the current communication. An ASP.NET based website usually maintains session variables to track a user by creating a cookie called ASP.NET_SessionId in the browser. A Session variable is typically used to record the currently logged-in user and such cookie value is validated on each round-trip to ensure that the data being served is specific to that user. Here the following image describes the process of cookie-based authentication, where the user does the login operation to a vulnerable website and in return, the server issues this specific user a cookie token value for session management.


                                                                           Figure: 1.1

Websites usually, engage session management to construct a user-friendly environment. But this mechanism is vulnerable in some extent because session IDs present an attractive target for attackers that is stored on the server and associated with respective users by a unique session identifier value. There are a couple of approaches applied by the attacker to perform a session fixation attack, depending on the session ID transport mechanism (cookies, hidden fields and URL arguments) and the loopholes identified on the target system.

The mechanics of session management is that the server generates a unique session identifier value during user authentication and sends this session ID back to the client browser and ensure that this same ID will be returned by the browser with each forthcoming request. Hence, such a unique session ID value thereby becomes identification tokens for users and servers can use them to maintain session data.


                                                                        Figure: 1.2

An ASPNET_SessionID cookie is only configured by the server on behalf of any page request of the website. So when the login page is first accessed, the ASP.NET_SessionID cookie value is set by the client browser and the server uses such a cookie value for all subsequent requests even after authentication is successful and logged out, the ASP.NET_SessionID value does not change. This results in the possibility of session fixation attack, where a hacker can potentially sniff the traffic across the wire or physically access the victim machine in order to get the stored cookies values in the browser and fix a victim's session by accessing the login page, even if not having the actual user name or password. The following image shows the real-time session fixation attack scenario where a potential hacker sits somewhere in the network and intercepts the traffic that happens between the server and client. Here, the hacker employs a packet sniffer to capture a valid token session and then utilizes the valid token session to gain unauthorized access to the Web Server. Finally, the hacker successfully accesses the ASPNET_SessionID value and logs in successfully to the website sensitive zone.


                                                            Figure: 1.3

Vulnerable Code Scenario

With session fixation, usually bugs occur on the website that manipulate sensitive data in a transaction or incorporated with a login page to authenticate valid users on behalf of the correct user name and password. This paper illustrates this crucial bug in detail by presenting this vulnerable login authentication code as in the following:

if (txtUsr.Text.Equals("frank") && txtPwd.Text.Equals("password"))
{
   Session["LIn"] = txtU.Text.Trim();
   Server.Transfer("Home.aspx");
}
else
{
   lblMessage.Text = "Wrong username or password";
}

When the user browses to this website and enters his valid credentials for authentication, the internal mechanism flashes the server message that either the user name and password is correct or incorrect as in the following:


                                                      Figure: 1.4

The user typically assumes that his transaction is safe and has less possibility of happening other website related attacks because entering to sensitive zones of web pages could happen after being validated first from the login page that is checking the correct credentials, But still, a couple of serious attacks such as spoofing, replay and session hijacking attacks could be possible even if managing user name and password correctly that we shall see in forthcoming segments of this article series.

Stealing Cookies

Valid session IDs are not only recognized to be identification tokens, but also employed as an authenticators. Users are authenticated based on their credentials (for example: user names and passwords) while login and issued session IDs that will effectively serve as temporary static passwords for accessing their sessions that makes session IDs a very appealing target for attackers. The moment the user enters his credentials on login to authenticate, the data stored in the session and cookies is generated in the client browser. A user is typically over-confident that when he ha logged out all the data is scrubbed automatically and the session is terminated, but unfortunately cookie values are not deleted from the client browser even if the session has ended and such cookies values can be exploited by a hacker to breach into the website sensitive zone without being aware of the user name and password. As the following figure shows, when a user is logged in, the browser shows cookie values that are generated during authentication.


                                                                                 Figure: 1.5

Now, log out and refresh the page. It is generally assumed that cookie values should be wiped out automatically when ending the current session but even after properly signing out from the current session, that is performing Session.Abandon() and Session.Clear() implicitly but the browser still shows the previous session generated cookies values as in the following.


                                                               Figure: 1.6

Hence, revealing cookies values even without being logged in could be considered a serious threat and can open the doors of session hijacking attacking. A malicious hacker could directly access the sensitive zone of a website without being logged in by adding such retrieved cookies details manually to the browser. Here, the attacker typically, uses this technique to inject the stolen cookies in the browser to hijack some other current session as in the following:


                                                Figure: 1.7

Defense (Securing Cookies)

Countermeasures combine several approaches to overcome such session hijacking kinds of attacks. For instance, making a cookie value bullet-proof by HttpOnly, explicitly removing session cookie values, employing HTTPS/ TLS (via Secure Attribute) and proper configuration. This section fixes the session hijacking vulnerability in the previous code where cookies values are not discarded even after logged-out, by generating another cookies having a unique value that is compared to a session value at each round-trip. Resemblance of both of these values, could allow the user to enter into the website sensitive zone, otherwise redirected toward the login page. This generates a unique value that can never be duplicated and there is a very low chance that the value of the new GUID is all zeroes or equal to any other GUID. Hence, such applied random token ensures protection against CSRF attacks in a website.

protected void Page_Load(object sender, EventArgs e)
 {
        if (Session["LIn"] != null && Session["AuthToken"] != null
                           && Request.Cookies["AuthToken"] != null)
        {
            if (!Session["AuthToken"].ToString().Equals(
                           Request.Cookies["AuthToken"].Value))
            {
                lblMessage.Text = "You are not logged in.";
            }
            else
            {
                ..
            }
        }
        ..
 }

This time in the Sign-in button, another unique value GUID is generated and stored with the session variable AuthToken that is added to cookies later as in the following.

protected void btnLogin_Click(object sender, EventArgs e)
{

       if (txtUsr.Text.Equals("frank") && txtPwd.Text.Equals("password"))
       {
           Session["LIn"] = txtU.Text.Trim();
           string guid = Guid.NewGuid().ToString();
           Session["AuthToken"] = guid;
           // now create a new cookie with this guid value
           Response.Cookies.Add(new HttpCookie("AuthToken", guid));
       }
     ..
}

Finally, the Log-out button has the code to expire the session cookies value explicitly that is now removed from the client browser permanently. Here, we shall need to remove both session ASP.NET_SessionId and AuthToken variable as in the following:

protected void btnLogout_Click(object sender, EventArgs e)
 {
        Session.Clear();
        Session.Abandon();
        Session.RemoveAll();

        if (Request.Cookies["ASP.NET_SessionId"] != null)
        {
            Response.Cookies["ASP.NET_SessionId"].Value = string.Empty;
            Response.Cookies["ASP.NET_SessionId"].Expires = DateTime.Now.AddMonths(-20);
        }

        if (Request.Cookies["AuthToken"] != null)
        {
            Response.Cookies["AuthToken"].Value = string.Empty;
            Response.Cookies["AuthToken"].Expires = DateTime.Now.AddMonths(-20);
        }
 }

Ok, now browse to the website again and login with the correct credentials and compare the output in the firebug with the previous output shown in Figure 1.5, here another session value AuthToken with new cookies is generated as in the following.


                                                                           Figure: 1.8

Thereafter, sign-out from the current session like as earlier and refresh the page and notice the cookies section in the firebug again, Bingo! This time the browser doesn't retain any previously stored cookie values. Hence, making cookie values bullet-proof ensures protection against session fixation attacks.


                                                                      Figure: 1.9

Final Note

This article has explained the session fixation attack on an ASP.NET website in details by providing a realistic code scenario and also pinpoints the common glitches committed by programmers when coding sensitive parts like login pages. We have seen how a potential hacker can access the cookie values stored in the client browser to execute a session hijacking attack and breach into the sensitive zone of a website, even without being aware of or having the real user name and password. Finally, we have come to an understanding of how to secure or make bullet-proof the cookie session values to protect our website from session fixation attacks.