Click here to Skip to main content
Click here to Skip to main content

Tagged as

Go to top

Session Fixation vulnerability in ASP.NET

, 14 Jun 2011
Rate this:
Please Sign up or sign in to vote.
In this article, we are going to learn how to avoid the Session fixation vulnerability in ASP.NET.
This is an old version of the currently published article.

Introduction

ASP.NET Session keeps track of the user by creating a cookie called “ASP.NET_SessionId” in the user browser. This cookie value is checked for every request to ensure that the data being served is specific to that user. In many application, Session variable is used to track the logged in user, ie. If a session variable exists for that user then the User is logged in otherwise not.

Background - The Vulnerability 

Whenever any data is saved into the Session, “ASP.NET_SessionId” cookie is created in the user’s browser. Even if the user has logged out (means the Session data has been removed by calling Session.Abandon() or Session.RemoveAll() or Session.Clear() method),  this “ASP.NET_SessionId” cookie and its value is not deleted from the user browser. This legitimate cookie value can be used by hijacker to hijack the user session by giving a link that exploits Cross Site scripting vulnerability to set this pre-defined cookie. When the user clicks this link and logs in, user will have the same “ASP.NET_SessionId” cookie value that hijackers knows and he will be also able to browser user account and will be able to access all information pertaining to that user. This attack is called Session fixation vulnerability. 

Get hundreds of Tips and Tricks like this in .NET How to Tips and Tricks.

Let’s create a demo application that shows the existence of “ASP.NET_SessionId” cookie even if the user has logged out and all Session data has been removed. 

ASPX Page

<fieldset>
    <legend>Login</legend>
    <p>Username : <asp:TextBox ID="txtU" runat="server" /> </p>
    <p>Password : <asp:TextBox ID="txtP" runat="server" /> </p>
    <p><asp:Button ID="btnSubmit" runat="server" 
            Text="Login" OnClick="LoginMe" />
    <asp:Label ID="lblMessage" runat="server" EnableViewState="false" />
    <asp:Button ID="btnLogout" runat="server" 
            Text="Logout" OnClick="LogoutMe" Visible="false" />
    </p>
</fieldset>

In the above code snippet, we have two TextBoxes, two Buttons and a Label control. 

Code=behind

protected void Page_Load(object sender, EventArgs e)
{
    if (Session["LoggedIn"] != null)
    {
        lblMessage.Text = "Congratulations !, you are logged in.";
        lblMessage.ForeColor = System.Drawing.Color.Green;
        btnLogout.Visible = true;
    }
    else
    {
        lblMessage.Text = "You are not logged in.";
        lblMessage.ForeColor = System.Drawing.Color.Red;
    }
}

protected void LoginMe(object sender, EventArgs e)
{
    // Check for Username and password (hard coded for this demo)
    if (txtU.Text.Trim().Equals("u") && txtP.Text.Trim().Equals("p"))
    {
        Session["LoggedIn"] = txtU.Text.Trim();
    }
    else
    {
        lblMessage.Text = "Wrong username or password";
    }
}

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

On click of the Login button, LoginMe method fires that creates Session[“LoggedIn”] after validating the TextBoxes value.

On click of the Logout button, we are calling Session.Clear()Session.Abandon() and Session.RemoveAll() methods to ensure that the session variable is removed.

Output

ASP.NET_SessionId  cookie when user is logged in

Notice in the below image that when user has logged in, an “ASP.NET_SessionId” cookie has been created.

Itfunda_1896_1.JPG

(After clicking on Login, go back and refresh the page)

Now when we clicked on Logout button, even if the Session has been abandoned / removed, the “ASP.NET_SessionId” cookie exists.

ASP.NET_SessionId  cookie even if user is logged out

Itfunda_4103_2.JPG

(After clicking on Login, go back and refresh the page)

How to fix this vulnerability 

Simple fix

To avoid Session fixation vulnerability attack, we can explicitly remove the “ASP.NET_SessionId” cookie in the Logout method.

Bullet proof fix 

To bullet proof this attack, we can create another cookie (e.g., AuthCookie) with a unique value and the same value can be stored into the Session as well. On every page load, we can match this cookie value with the Session value, if both matches then let the use enter into the application otherwise redirect to the Login page.

In the Logout function, ensure that you are removing this new Cookie “AuthCookie” as well. To remove this cookie, simply set its expiration date time to few months earlier than current date time.

So my modified code behind for this page looks like below:

Modified code-behind

protected void Page_Load(object sender, EventArgs e)
{
    //NOTE: Keep this Session and Auth Cookie check condition in your Master Page Page_Load event
    if (Session["LoggedIn"] != null && Session["AuthToken"] != null 
           && Request.Cookies["AuthToken"] != null)
    {
        if (!Session["AuthToken"].ToString().Equals(
                   Request.Cookies["AuthToken"].Value))
        {
            // redirect to the login page in real application
            lblMessage.Text = "You are not logged in.";
        }
        else
        {
            lblMessage.Text = "Congratulations !, you are logged in.";
            lblMessage.ForeColor = System.Drawing.Color.Green;
            btnLogout.Visible = true;
        }
    }
    else
    {
        lblMessage.Text = "You are not logged in.";
        lblMessage.ForeColor = System.Drawing.Color.Red;
    }
}

protected void LoginMe(object sender, EventArgs e)
{
    // Check for Username and password (hard coded for this demo)
    if (txtU.Text.Trim().Equals("u") && txtP.Text.Trim().Equals("p"))
    {
        Session["LoggedIn"] = txtU.Text.Trim();
        // createa a new GUID and save into the session
        string guid = Guid.NewGuid().ToString();
        Session["AuthToken"] = guid;
        // now create a new cookie with this guid value
        Response.Cookies.Add(new HttpCookie("AuthToken", guid));

    }
    else
    {
        lblMessage.Text = "Wrong username or password";
    }
}

protected void LogoutMe(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);
    }
}

LoginMe method

First focus on the LoginMe method that fire on click of the Login button.  In this method, after setting the normal Session variable, we are creating a GUID (a unique value and almost impossible to guess) and saving it as a new Session variable called “AuthToken”. The same GUID is being saved into a cookie named “AuthToken”.

LogoutMe method 

In the LogoutMe method, we are first explicitly expiring the “ASP.NET_SessionId” cookie to make sure that this cookie is removed from the browser when user clicks on the Logout button and after that we are expiring the “AuthToken” cookie as well.

Page_Load  event  (In real time application, keep this logic into the Master Page  Page_Load method)

In the Page_Load event we are checking for the normal “LoggedIn” session variable and along with that we are also checking for the new Session variable called “AuthToken” and new Cookie “AuthToken”, if all three of them are not null then again we are matching the new Session variable “AuthToken” and new Cookie “AuthToken” values, if both are not same, then we are writing failure message (in real time application, redirect the user to the Login page). 

This logic makes sure that even if “ASP.NET_SessionId” cookie value is known to the hijacker, he will not be able to login to the application as we are checking for the new Session value with new cookie that is created by us and their GUID value is created by us. A hijacker can know the Cookie value but he can’t know the Session value that is stored into the web server level and as this AuthToken value is changing every time user is logging in so the older value will not work and hijacker will not be able to even guess this value. Unless the new Session (“AuthToken”) value and new Cookie (“AuthToken”) is same, no one will be able to login to the application. 

OUTPUT 

ASP.NET_SessionId along with AuthToken cookie

Itfunda_6193_3.JPG

Hope you find this article interesting, thanks for reading. Subscribe to our RSS feed to read more articles on regular basis.

Originally posted here.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

ITFunda
IT Funda Corporation
India India
Provide online .NET training and training materials.
Follow on   Twitter

Comments and Discussions


Discussions posted for the Published version of this article. Posting a message here will take you to the publicly available article in order to continue your conversation in public.
 
GeneralThank you PinmemberHarikrishnanvr29-Mar-14 7:02 
GeneralMy vote of 5 PinmemberMacParekh28-Aug-13 21:07 
GeneralMy vote of 5 PinmemberMember 924146511-Jul-12 8:34 
Bug[My vote of 1] This is not session fixation, and the solution does not address session fixation Pinmembertoidy17-Oct-11 18:35 
GeneralRe: [My vote of 1] This is not session fixation, and the solution does not address session fixation [modified] PinmemberMember 924146511-Jul-12 8:14 
GeneralMy vote of 5 PinmemberArlen Navasartian11-Jul-11 6:43 
GeneralMy vote of 5 PinmemberRhuros10-Jul-11 23:44 
GeneralMy vote of 2 PinmemberSumit Kumar Pranav20-Jun-11 22:08 
GeneralMy vote of 5 Pinmemberkoolprasad200315-Jun-11 20:22 
GeneralMy vote of 5 PinmvpShivprasad koirala15-Jun-11 4:44 
GeneralMy vote of 5 PinmemberAnurag Gandhi14-Jun-11 23:41 
Generalnice tip Pinmemberrubiwachs14-Jun-11 20:59 
GeneralWhat if i hijack both cookies? PinmemberHaBiX14-Jun-11 20:58 
GeneralRe: What if i hijack both cookies? PinmemberITFunda17-Jun-11 0:36 
GeneralRe: What if i hijack both cookies? PinmemberHaBiX17-Jun-11 1:01 
GeneralRe: What if i hijack both cookies? Pinmembertoidy17-Oct-11 18:39 
GeneralMy vote of 5 PinmemberMonjurul Habib14-Jun-11 11:14 
GeneralRe: My vote of 5 PinmemberITFunda14-Jun-11 15:07 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.140916.1 | Last Updated 14 Jun 2011
Article Copyright 2011 by ITFunda
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid