Improper handling of session variables in asp.NET websites is considered a serious threat and opens various doors to malicious hackers. For instance, a session variable could be manipulated in a way to subvert login authentication mechanisms. However, this article illustrates a session fixation bug in a .NET website by demonstrating various live scenarios which usually leads to a website becoming vulnerable, in terms of session hijacking. Moreover, the article circulates detailed information about exploiting vulnerable websites, as well as recommendations of practices for protecting them against session fixation attacks.
Internal Session Fixation
A session fixation attack allows spoofing another valid user and working on behalf of their credentials. It typically fixates another person’s session identifier to breach currently happening communication. The asp.NET base website usually keeps session variables to track the user by creating a cookie called asp.NET_SessionId in the browser. A session variable is typically used to record a currently logged-in user, and such a cookie value is validated on each round-trip to ensure that the data being served is specific to that user. Here the following image is describing the process of cookies-based authentication, where the user performs the login operation to a vulnerable website, and in return, the server issues this particular 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 to some extent, because session IDs present an attractive target for attackers, as they are stored on a server and associated with respective users by unique session identifier values. 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 makes sure that this same ID will be sent back by the browser along with each forthcoming request. Hence, such a unique session ID value thereby becomes an identification token for users, and servers can use them to maintain session data.
Figure: 1.2
An asp.NET_SessionID cookie is only configured by the server whenever working 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 server uses this 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 a 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 cookie values in the browser and fix a victim’s session by accessing the login page, even if they don’t have 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 happening between a 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 asp.NET_SessionID value and logs in successfully to the website’s sensitive zone.
Figure: 1.3
Vulnerable Code Scenario
Session fixation bugs usually occur on websites which manipulate sensitive data while transacting or incorporating with the login page to authenticate valid users with correct user name and password. This paper illustrates this crucial bug in detail by presenting this vulnerable login authentication code as follows:
1
2
3
4
5
6
7
8
9
| if (txtUsr.Text.Equals("frank") && txtPwd.Text.Equals("password")){ Session["LIn"] = txtU.Text.Trim();}else{ lblMessage.Text = "Wrong username or password";} |
When a user browses this website and enters the valid credentials for authentication, the internal mechanism flashes the server message that either the user name and password are correct or incorrect as follows:
Figure: 1.4
The user typically assumes that this transaction is safe and there are fewer possibilities of other website-related attacks, but still, a couple of serious attacks such as spoofing, replay and session hijacking attacks could be possible, even if managing the user name and password correctly. We shall see this in a forthcoming segment of this article.
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 login credentials (e.g. user names and passwords) and are issued session IDs that will effectively serve as temporary static passwords for accessing their sessions, which makes session IDs a very appealing target for attackers. The moment a user enters his credentials on login to authenticate, these data are stored in the session and cookies are generated in the client browser. The user is typically over-confident that when he is logged out, all the data would be scrubbed automatically and the session is terminated, but unfortunately, the cookie values are not deleted from the client browser, even if the session is ended, and such cookie values could be exploited by a hacker to breach into the website’s sensitive zone, without being aware of user name and password.
As the following figure shows, when a user is logged in, the browser shows cookie values which are generated during authentication as:
Figure: 1.5
Now log out and refresh the page. It is generally assumed that cookie values should be wiped-out automatically at the time of ending the current session, but even after proper sign-out from the current session, which is performing Session.Abandon(), Session.Clear() implicitly, the browser is still showing the previous session’s generated cookies values as follows:
Figure: 1.6
Hence, revealing cookie values even without being logged in could be considered a serious threat and opens the doors to a session hijacking attack. A malicious hacker could directly access the sensitive zone of a website without being logged in by adding such retrieved cookie details manually to the browser. Here, the attacker typically uses this technique to inject the stolen cookies in the browser to hijack the someone else’s current session as follows:
Defense (Securing Cookies)
Countermeasures combine several approaches to overcome such session hijacking attacks. For instance, making cookie values 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 aforesaid code, where cookie values are not discarded even after logout, by generating another cookie having a unique value which is compared to the session value at each round-trip. Resemblance of both of these values could allow the user to enter into the website’s sensitive zone; otherwise the user is redirected to the login page. This generates a unique value never to 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 an applied random token ensures protection against a CSRF attack in a website.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| 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 AuthTokenwhich is added to cookies later as follows:
1
2
3
4
5
6
7
8
9
10
11
12
13
| 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 logout button has the code to expire the session cookie values explicitly, which removes them from the client browser permanently. Here, we shall have to remove both session asp.NET_SessionId and AuthToken variables as follows:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| 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); } } |
Okay, now browse 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 follows:
Figure: 1.7
Thereafter, sign out from the current session 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 to protect against session fixation attack.
Figure: 1.8
Final Note
This article has explained the session fixation attack on asp.NET website in detail by giving the real time code scenario, and also pinpoints the common glitches committed by programmer at time of coding of sensitive parts like login pages. We have seen how a potential hacker can access the cookies values stored in the client browser in order to execute a session hijacking attack and breach into the sensitive zone of a website, even without being aware or having a real user name and password. Finally, we have come to an understanding to secure or make bullet-proof the cookie session values to protect our website from session fixation attack.
No comments:
Post a Comment