Broken Authentication And Session Management And Its Prevention Mechanism

Weak session management and authentication is a cause for a web application's security flaw, which results in the failure to protect the session tokens and the credentials through their lifecycle. These flaws can lead to the stealing of the administrative or user accounts and privacy violations.

What is this vulnerability?

If authentication and session management are not implemented correctly, it allows the attackers to compromise session tokens or passwords, keys or to exploit the other implementation flaws to assume other users' identities. Authentication verifies the identity for the given credentials such as a username and password. Authentication and session management breaks the reasons such as insecure communication channels, password cracking etc.

Risks

• Undermined authorization and accountability controls.
• Cause privacy violation.
• Identity theft.

We can implement authentication in two ways as below

• Cookie Based Authentication(old approach), which uses the server side cookies to authenticate the user on each request.
• Token Based Authentication(new approach) depends on a signed token, which is sent to the Server on each request.

Token based approach and Cookie based approach

As we know, when we use the cookie based approach, the generated ASP_SessionId will be stored in the Browser cookies. When we use a token-based approach, the generated token will be stored in the Browser Cookies and with every request, the generated token will be passed as an attribute of the request header.

The following diagram explains how both the methods work:

Advantages of using a token-based approach

• CORS
  Cookies are a Token-based approach, which allows you to make the AJAX calls to any domain, any Server because you use HTTP header to transfer the user data.
  
  
• Stateless (Server side scalability)
  There is no need to keep a session store. The token is a self-contained entity, which passes all the user information and the rest of the state lives in the cookies or local storage on the client side.
  
  
• CDN
  You can refer  to the required client side scripts from a CDN (e.g. JavaScript, HTML, images, etc.) and your Server side is just API.
  
  
• Mobile ready
  When you start working on a native platform like Windows 8, Android, iOS etc., cookies are not perfect, when consuming a secure API. Using a Token-based approach simplifies this a lot.
  
  
• CSRF
  As you are not depending on the cookies, you have no need to protect against cross site requests.
  
  
• Standard-based
  Your API methods can accept a JSON Web Token (JWT). This is standard and there are multiple frameworks like .NET, Ruby, Java, Python and PHP etc. For instance, Firebase allows its customers to use any authentication approach, as long as you produce a JSON Web Token with the certain pre-defined attributes and signed with a shared secret to call their API.

Advantages of using a cookie-based approach

Compared to Token-based authentication, I don't find any good advantages in Cookie-based authentication.

The Problems with Cookie Based Authentication

A few major problems may arise with this method of authentication.

• Sessions
• Scalability
• CORS
• CSRF

Malicious attack when we use cookie-based approach

Before starting the malicious attack example, we have to add few add-ons in the Browsers: Here, I prefer Firefox and Chrome Browsers for the example, given below:

Steps to add a few add-ons in browsers

Step 1: In Google, browse for “edit cookie in Firefox” and you will get many links, as given in the screenshot, below:



I have added one add-on in Firebox Browser from the screenshot, shown above. After you add the add-on, you will find one option in the Browser cookie with the name “Edit”. Refer to the screenshot, given below:



Step 2: This is the same way you have to do it for Chrome Browser.

In Google, browse for “edit cookie chrome”, you will get many links, as given below. From the screenshot, given  y can add the top two add-ons.



I have added the top two add-ons in Chrome Browser from the screenshot, shown above. After you add the add-ons, you will find two options in your Chrome Browser, as shown below:



From the screenshot, shown above, you can select any option to edit your cookie. For reference, find the screenshot, given below, to see, how the editors will look:



Now, it’s time to show you how to hijack the session key from one Browser. Let's say Firefox to another Browser.

Step 1

Let's say, you logged in with the user credential "Test1 / test123" in Firefox Browser, the unique session key will generate with the name "ASP.NET_SessionId", make a note as each time the login session key will differ. After Login, how the session key looks is depicted below:

Login screenshot



After Login


After logging in to Firefox Browser, if you observe the screenshot, shown above, ASP.NET_SessionId with the value “2e3yo3htzmddvi5uw3xzukls”got created in browser cookie.

Step 2

If you copy the URL from Firefox Browser, paste in Chrome Browser, hit enter key and it will send you to Login screen, as shown below:

Firefox browser URL: http://localhost:62887/EditPOInjection.aspx?POID=1

After pasting the URL, shown above, from Firefox Browser to Chrome Browser, it will send you to the login screen:



If you observe the screenshot, shown above, the session Id is “z5egra3t0rbxymb1gu5qi4rf”, which is different from Firefox Browser. As the session Id is different that is why it automatically redirected to login screen.

Step 3

Now if you copy ASP.NET_SessionId from Firefox browser and change the Chrome browser's session id with copied ASP.NET_SessionId value and again request to the URL, given below, in Chrome browser then:

URL request

http://localhost:62887/EditPOInjection.aspx?POID=1

Screenshot after changes made for ASP.NET_SessionId:



URL request after ASP.NET_SessionId changes made:

http://localhost:62887/EditPOInjection.aspx?POID=1

Output


Prevention mechanism for cookie-based token

Step 1

Generate a Hash key with the logged in Browser information like the Browser version, platform, Browser minimum version and Browser maximum version etc. In the code, given below, “GenerateHashKey()” method generates a Hash key for the logged in user and we are assigning the generated Hash key into one session variable with the name “SessionHashKey”. As we know, the session variable keeps the assigned value, until the session is in the active state.



Destination page code behind file

In our destination page code at the backend file, we are validating with the “SessionHashKey” session key value. If the request matches with the “SessionHashKey” session key value, it will redirect to the destination page. If it does not match with the “SessionHashKey” session key value, it will redirect to the login page.



Note: To prevent this type of attack, we can validate in all the pages. As “GenerateHashKey()” method is needed in all the pages to validate the request. We can place “GenerateHashKey()” method in our “Utility” project so that it will be available in all projects.

Malicious attack when we use token-based approach

If you are not using strongly typed encrypted token then you are giving an opportunity to decrypt the token. Once the token is decrypted then you lost your control and the hacker will take the control. So we have to use strong encryption mechanism like Bearer or JWT token with Sign mechanism.

Let’s take an example, if you are using weekly typed token with the token based basic authentication, see how the attacker can break it.

Here, I have written the custom attribute to validate the user:



In our login API method, we are generating a token by taking user logged in credential as an input.



Once the login is successful, in the client side success event, we are storing the generated token in the session storage variable, as shown below:



Now, we add this generated token in the header part of all the corresponding requests to validate the authenticated user. Sample code is given below:



When we execute API method and if you see in the Browser developer tool in the request header, we will find one property with the name “Authorization” with the generated token. Refer to the screenshot, given below, for reference:



Now, if you change the generated token, using the Browser developer tool, it will send you to the login screen again. Screenshot to change the generated token, using the developer tool is given below:



Let's say, this token is generated in Firefox Browser for one logged in user. Now,  login with the different user in Chrome Browser and change the generated token with Firefox token which is generated for different user login. It will allow you to perform CRUD operations, even though you are an not authentic user.

Prevention mechanism for token-based approach

Create a custom token and apply strong encryption mechanism, using MD5, SHA etc. With every request, validate the token by decrypting it in the code at the backend file and comparing it with the logged in user information. If everything is fine, process the given request otherwise respond with the proper warning message. Make sure, while creating your custom token, you are considering MAC Id also. If you consider MAC Id, while creating your custom token, it will prevent CSRF attack as well. The main idea to consider with MAC Id is, when we consider MAC Id; the hacker cannot hack your data either from the same system (where the authenticated user is working) or from the different system (from where the hacker is trying to hack).