Broken Authentication and Session Management – Part2

From the previous article, we know what exactly a Session is. In this article, we will learn about Session Fixation. For a better illustration, I have created a simple application built on ASP.NET. You can download the project from my Github, here. This project has two folders ‘SecureLoginFunc’ & ‘InsecureLogin‘ which contain a login & logout mechanism of the application. Import the downloaded project into Visual Studio or create and configure the web app in your local IIS.

As you know, a session is used to track the user activity using a Cookie. In ASP.NET, the server creates a cookie named as ‘ASP.NET_SessionId‘ on the client. This ‘ASP.NET_SessionId’ cookie value will be checked for every request to ensure the authenticity & Identity. ASP.NET has two ways of transmitting session IDs back and forth to the browser, either embedded in the URL or through a session cookie. You can easily spot the session ID when it’s embedded in the URL, for example ‘www.abc.com/(S(dacaanfdgasdfdadfghq))’

What is Session Fixation

Session Fixation is a specific attack against the session that allows an attacker to gain access to a victim’s session. Attacker visits the website to obtain a valid Session. This valid session cookie is placed in the victim’s browser. When the victim logs into the website, both attacker and victim will use the same session cookie that the attacker already knows, and thus the attacker-owned cookie is now authenticated and can be exploited.

Let’s look this vulnerability in practical using ASP.NET application. Once you import the project in Visual Studio, open the file ‘Login.aspx.cs‘ in ‘InsecureLogin’ folder. This is a code behind file for our login functionality. As you see there are two events ‘Page_Load’ & ‘btnSubmit_Click‘. On the click on Login Button, the event ‘btnSubmit_Click‘ will be triggered. Let’s understand the code before running the application. When the user provides valid credentials, a Session ‘userLoggedin‘ would be created and this gets stored on the server side. Once Login processed, the user will be redirected to the ‘Welcome‘ Page which has a log out button.

Open the file ‘Welcome.aspx.cs‘ in ‘InsecureLogin’ folder. This is a code behind the file for the welcome page. Once the user is redirected to this page, an event ‘Page_Load’ would be triggered first. And this event would check the value of the Session is not null and enables the logout button. When user clicks on Logout button, ‘btnLogout_Click’ event will be triggered which clears the Session and redirect the user to Login Page

Now run the web form Login.aspx (Press F5) from the visual studio. Press F12 to view the cookies before Logging into the application.

Once you login with valid credentials, a cookie ‘ASP.NET_SessionId‘ would be created. For better understanding, I have captured the value of the cookie and displayed it on the Welcome-page.

As per our understanding from the code review, when a user clicks on Logout button, the session has to be terminated. But if you notice, the cookie ‘ASP.NET_SessionId’ still exists and is still valid. This valid cookie value can be used by the attacker to hijack the user session using few techniques such as Phishing, Cross site scripting as a link which exploits to set this pre-defined cookie on victims browser. When the user clicks this link and logs in, the user will have the same ASP.NET_SessionId cookie value that attacker knows and he can gain access to the user account. This attack is known as Session Fixation.

Countermeasures

As you have seen that the cookie ‘ASP.NET_SessionId‘ wasn’t deleted on user Logout. So we need to delete this cookie explicitly on the logout event. But it really won’t solve the problem. Since we are entirely relying on one cookie ‘ASP.NET_SessionId’, anyone having this cookie can gain access to the account. This can be achieved by sniffing/MITM (Man in the middle attacks). So to overcome this problem we will create another cookie ‘AuthToken‘ having random GUID as value.Also, we will create another session ‘AuthToken‘ with same random GUID as value. Let’s see it in practice. Go to the folder ‘SecureLoginFunc’ and open ‘SecureLogin.aspx.cs‘. As you see, on click of Login button, the event ‘btnSubmit_Click‘ will be triggered. This event creates two Sessions one for user authenticity and other sessions for integrity.

Once user login with valid credentials, two sessions and cookie will be created and the user will be redirected to the ‘SecureLogout’ page. Open ‘SecureLogout.aspx.cs‘ code behind file. On the page load, we are checking three conditions. Both the sessions and cookies should not be null. And the value of Session ‘AuthToken’ must be equal to the value of cookie ‘AuthToken’. Since ‘AuthToken’ value is a random GUID, it's practically impossible to predict the AuthToken value. If any of the conditions fail, the user will be redirected to the login page.

When the user clicks on the Logout button, ‘btnLogout_Click‘ event will be triggered. This event removes all the sessions. Also, we explicitly removed the values of cookies ‘ASP.NET_SessionId‘, ‘AuthToken‘ so that an attacker cannot fixate the session.

Apart from the above implementation, use HTTPOnly, Secure flags for cookies. Also never use Cookieless sessions, since the session can be easily manipulated in the query strings. Implement Session Timeout for short span of time.

References:http://www.acros.si/papers/session_fixation.pdfhttp://resources.infosecinstitute.com/hunting-session-fixation-bug/https://support.microsoft.com/en-us/help/899918/how-and-why-session-ids-are-reused-in-asp-net