Session Fixation - Exercise

Introduction

 

If you look at the OWASP top 10 list from 2010 – 2017, you will find that Broken Authentication has always been listed second. Bear in mind that the top 10 is listed in descending order of importance. In 2013 it was updated to Broken Authentication and Session Management but in 2017 it was updated again to Broken Authentication but it remained on the second of the list.

 

Authentication is of great importance in any web application and it is a major security concern. Why? This is because the authentication process validates who is going to have access to what in the web application it restricts or gives access after cross-checking their credentials so there is a need for developers to come up with a strong authentication process that ensures that attackers are denied access and legitimate users are given their requests by the application. Once a legitimate user has logged in the web application ASP.NET generates a Session ID. ASP.NET web applications keep track of the user by creating a cookie called ASP.NET_SessionId in the user browser. The SessionId cookie remains in the browser even if the user has logged out so that it remembers the user when they log in again and make requests.

 

Session vs. Identity in ASP.NET Web Applications

 

Developers usually let Forms Authentication or Windows Identity Foundation (WIF) keep track of users when they are logged in to an ASP.NET application. By default, both Forms Authentication and WIF store the user's identity information in a cookie and make use of the Message Authentication Code (MAC) to encrypt the information. MAC ensures that the stored cookie cannot be tampered with and encryption ensures that even if a third party has access to this cookie they cannot easily read its contents and misuse it. These cookies are usually referred to as “authentication cookies”. The FormsAuthenticationModules manages the Forms Authentication cookies, in the default configuration, and marks them with a “.ASPXAUTH” extension whilst WIF SessionAuthenticationModule handles the cookies marking them with a “FEDAUTH” extension by default. These modules will set the Principal and User objects on the Http Context for each request, based on the content of the authentication cookies.

 

On the other hand, SessionStateModule will manage the ASP.NET session state, and it does so without regard to the identity of the current user. At the end of the day, there no connection between the user's identity and the ASP.NET session. The Session ID is by default managed by the built-in SessionIDManager which among other things takes care of the creation and validation of session identifiers.

 

Therefore, it is important to note that the user's identity and the user's session are two separate things. ASP.NET will accept any session from the browser as long as it is structurally valid. This paves a way for vulnerability to the Session Fixation attack.

 

Session Fixation

 

Attackers are attracted to Session IDs since they can use them to get unauthorized access to user's accounts. Vulnerabilities such as exposing Session IDs in the URL can be used by attackers to get access to user's accounts with the use of the Session ID. On the other hand, Session Fixation does not require the attacker to have a session ID.

 

“Session Fixation is the opposite of obtaining the user’s session ID, rather it involves the attacker fixing the user’s Session ID before the user even logs on, which eliminates the need to obtain the user’s Session ID at all.”

 

The Vulnerability

 

The data stored in the ASP.NET_SessionId is not deleted from the user’s browser if we use the Session.Abandon() or Session.RemoveAll() or Session.Clear() methods when the user logs out. The ASP.NET_SessionId cookie can still be used by an attacker to hijack the user's session by giving a link that exploits cross-site scripting vulnerability to set this pre-defined cookie. If the user clicks this link and logs in, the user will have the same ASP.NET_SessionId cookie value that the attacker knows and he will have access to the user’s information and account and this is a Session fixation attack

 

Let's look at a Session fixation practical example using VB.Net:

1. We will start by creating a new project in Visual Studio but will not show those steps in this case we assume you are familiar with the VS development environment.
2. We want to make use of 2 web pages one for logging in and the other as a welcome page.

Login page ASPX code:

 <%@ Page Language="vb" AutoEventWireup="false" CodeBehind="Testpage.aspx.vb" Inherits="Test.Testpage" %>
<!DOCTYPE html>
<html
    xmlns="http://www.w3.org/1999/xhtml">
    <head runat="server">
        <title>Log in</title>
    </head>
    <body>
        <form id="form1" runat="server">
            <div>
                <h4>Session Fixation</h4>
                <div class="row">
                    <asp:Label ID="lblMsg" runat="server" Text=""></asp:Label>
                    <br/>
                    <div>
                        <asp:Label ID="Label1" runat="server" Text="User Name"></asp:Label>
                        <asp:TextBox ID="txtusername" runat="server" ></asp:TextBox>
                    </div>
                </div>
                <br/>
                <div class="row">
                    <div>
                        <asp:Label ID="Label2" runat="server" Text="Password"></asp:Label>


                        <asp:TextBox ID="txtpassword" runat="server"  TextMode="Password"></asp:TextBox>
                    </div>
                </div>
                <br/>
                <div class="row">
                    <div style="padding-left:50px;">
                        <asp:Button ID="btnlogin" runat="server"  Text="Login" OnClick="btnlogin_Click" ></asp:Button>
                    </div>
                </div>
            </div>
        </form>
    </body>
</html>

Login Page Code-Behind

Public Class Testpage
   Inherits System.Web.UI.Page
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
End Sub
Protected Sub btnlogin_Click(sender As Object, e As EventArgs)
If txtusername.Text.Trim().Equals("user") AndAlso txtpassword.Text.Trim().Equals("password") Then
   Session("UserLogin") = txtusername.Text.Trim()
   Response.Redirect("Home.aspx")
Else
   lblMsg.ForeColor = System.Drawing.Color.Red
   lblMsg.Text = "Wrong username or password"
End If
End Sub
End Class

Welcome Page .aspx code

<%@ Page Language="vb" AutoEventWireup="false" CodeBehind="Home.aspx.vb" Inherits="Test.Home" %>
<!DOCTYPE html>
<html
    xmlns="http://www.w3.org/1999/xhtml">
    <head runat="server">
        <title>Welcome</title>
    </head>
    <body>
        <form id="form1" runat="server">
            <div>
                <asp:Label ID="lblmsg" runat="server" Text="" Font-Size="Larger" Font-Bold="true"></asp:Label>
            </div>
            <br/>
            <asp:Button ID="btnlogout" runat="server"  Text="Log Out" OnClick="btnlogout_Click" Visible="false"></asp:Button>
        </form>
    </body>
</html>

If you inspect the page, you will be able to view the ASP.NET_SessionId that has been created for your page. Notice that even if login and out of the sample application the ASP.NET_SessionId remains the same. This means at log out we are not removing the SessionID from our browser.

 

 

How to mitigate Session Fixation

 

Now that we have demonstrated how Session Fixation Vulnerabilities work, let's look at some of the ways to mitigate this vulnerability.

• One of the simplest ways to mitigate Session Fixation is to remove the ASP.NET_SessionId in the logout event. One can easily set the Session ID to null at log out.
• In your web.Config file you can set a specified time to expire the session.

Conclusion

 

In this article, we have demonstrated the vulnerabilities that pave way for session fixation to occur. Developers then need to scan test their web application for such vulnerabilities before deploying the application to the web where it is vulnerable to attacks.