How to Resolved Session Fixation Vulnerability in ASP.NET?

0
209
[Solution] : Session Fixation Vulnerability
[Solution] : Session Fixation Vulnerability

Session fixation vulnerability is very common in many session-enabled web apps. In my search for answers I found it extremely tough to search out any “fix all” solution. It appears to be a lot of concerning risk mitigation and creating it as difficult as possible for a potential attacker. Hopefully this article can assist you understand the vulnerability and maybe assist you prevent it.

1What is Session Fixation Vulnerability?

In short, a session fixation attack lets an attacker set her session identifier for one more user. The result would be a session shared between an attacker and also the victim. Once the user interacts with the web site sensitive information is added to the session. Since the user and also the attacker shares the session ID, the changes also will be reflected on the attacker’s end. Information keep in session could be disclosed in a web page, or it may be used to control access to protected resources. Either way, the attacker can gain access to data that should only be accessible to the user.

See this : Kotlin Problems and How to avoid them?

2How this Vulnerability works?

Basically, An ASP.NET based website usually maintains session variables to track a user by creating a cookie called ASP.NET_SessionId in the browser. A Session variable is typically used to record the currently logged-in user and such cookie value is validated on each round-trip to ensure that the data being served is specific to that user.

Session Fixation Vulnerability : After Login Page
Session Fixation Vulnerability : After Login Page

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 ensure that this same ID will be returned by the browser with each forthcoming request.

Hence, such a unique session ID value thereby becomes identification tokens for users and servers can use them to maintain session data.

Session Fixation Vulnerability : Cookies steal by attacker
Session Fixation Vulnerability : Cookies steal by attacker

An ASPNET_SessionID cookie is only configured by the server 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 the server uses such a cookie value for all subsequent requests even after authentication is successful and logged out, the ASP.NET_SessionID value does not change.

Must see : Digital Learning age – How to be the best student?

This results in the possibility of 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 cookies values in the browser and fix a victim’s session by accessing the login page, even if not having the actual user name or password.

Session Fixation Vulnerability : traffic sniffing by attacker
Session Fixation Vulnerability : traffic sniffing by attacker

This is a real-time session fixation attack scenario where a potential hacker sits somewhere in the network and intercepts the traffic that happens between the 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 ASPNET_SessionID value and logs in successfully to the website sensitive zone.

Check this too : How to add Social Media Sign Up Library in Android?

3How to resolve Session Fixation Vulnerability?

To avoid Session fixation vulnerability attacks,  we can create another cookie (e.g., SFToken) 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 the application otherwise redirect to the Login page.

Login Page

First of all you’ve to set cookies and session value of SFToken in Login page and before redirecting to success page.

// createa a new GUID and save into the session
string guid = Guid.NewGuid().ToString();
Session["SFToken"] = guid;
// now create a new cookie with this guid value
Response.Cookies.Add(new HttpCookie("SFToken", guid));
Code for Login page
Code for Login page

Welcome Page

Then check and validate the value of SFToken of Session and Cookies value in Welcome page and if it same then everything is fine otherwise redirect to login page.

if(Session["SFToken"] != null && Request.Cookies["SFToken"] != null)
    {
        if (!Session["SFToken"].ToString().Equals(Request.Cookies["SFToken"].Value))
        {
            // redirect to the login page in real application
      Session.Abandon();
      Response.Redirect("Login page");
        }
    }
    else
    {
        Session.Abandon();
      Response.Redirect("Login page");
    }
Code for Welcome Page
Code for Welcome Page

Log Out Page

Finally when you log out then clear all session and cookies including SFToken.

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["SFToken"] != null)
{
  Response.Cookies["SFToken"].Value = string.Empty;
  Response.Cookies["SFToken"].Expires = DateTime.Now.AddMonths(-20);
}
Code for Logout page
Code for Logout page

That’s it. Enjoy your application vulnerability free.

 

 

 

Share your thoughts

Loading Facebook Comments ...
Loading Disqus Comments ...