Broken Authentication and Session Management – part Ⅱ


Introduction
HTTP is a stateless protocol, hence web server does not maintain any track of user activity. To track user activity we generally use Sessions. There are various ways of session management where the server generates a session identifier (ID) initially and ensure that the same ID will be sent back by the browser along with each subsequent request. This helps us to maintain a record of user. Improper handling of these session variables could be a serious threat and allows attackers to gain access to the system. This article illustrates session fixation considering ASP.NET web application. For better understanding I have created a simple ASP.NET application. You can download the project from here. This project has two folders ‘SecureLoginFunc’ & ‘InsecureLogin‘ which contains login & logout mechanism of the application. You need to import the downloaded project to Visual Studio or create a virtual directory in IIS and add this project to it.

As you know a Session is used to track the user activity using a Cookie. In ASP.NET, 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))’. Anyway this is not recommended solution.

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 log 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 of Login Button, the event ‘btnSubmit_Click‘ will be triggered. Let’s understand the code before running the application. When user provide valid credentials, a Session ‘userLoggedin‘ would be created and this gets stored on the server side. Once Login processed, user will redirected to ‘Welcome‘ Page which has a logout button.

CreateSessionInsecureLogin

Now open the file ‘Welcome.aspx.cs‘ in ‘InsecureLogin’ folder. This is a code behind file for welcome page. Once user redirected to this page, an event ‘Page_Load’ would be triggered first. And this event would check the value of 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

Welcome1

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

Login1

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

Login2

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.

Login3

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 practical. 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 session for integrity.

SecureLogin1

Once user login with valid credentials, two sessions and cookie will be created and 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 value of cookie ‘AuthToken’. Since ‘AuthToken’ value is a random GUID, its practically impossible to predict the AuthToken value. If any of the condition fails, user will be redirected to the login page

SecureLogout2

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

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

References:
http://www.acros.si/papers/session_fixation.pdf
http://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

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s