• Aditya Anand

How to write secure code to protect yourself against Broken Auth & Session Management?

Need for Secure Code?

I have been working on secure coding practises and trying to learn as many essential points as possible. In the past few years of being in infosec, I have realised about the amount of damage a small vulnerability can have in the life of a common man. Cyber attacks like the WannaCry and Petya ransomware are pretty fresh in the mind of several people who suffered ’cause of it.

Still, every passing day researchers can find one after another highly severe bugs in the web apps and other domains. This trend won’t be going down unless programmers become self-aware about the code they are writing. The code shouldn’t just be able to carry out the intended work it is supposed to but also be able to fend off any malicious payload and attack scenarios. The best way to do that is by being able to make a synergy between the coding and the security community and help each other out.

Let’s dig in!

So, this particular article of “How to write secure code?” is focused on the Broken auth problem and the Session management issue.

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume the identity of another user.

In this article I will go through a few different types such attacks and methods you can use to prevent against them:-

1. Hard-Coding login credentials

Hard Coding login credentials is one of the most rookie mistakes a programmer can make as that is as good as serving credentials to the hackers on a silver platter. Sensitive data should never be hardcoded.

The code on the side is one of those examples where the login credentials are hardcoded in the code written by the programmer.

Whereas the code present below is an example where credentials are not hardcoded in the program making it exponentially more secure than the ones where the creds are hardcoded.

Such small differences can make a huge impact on the security of the application.

2. Cookie Manipulation

Cookie manipulation is rising as one of the most dangerous attacks that are carried out these days as more and more authentication process is carried out by checking the cookie details that are presented by the user.

Attackers are finding ways to break and figure out how the web apps assign cookies so as they can manipulate them and pose as some other user carrying out account takeover.

Let me demonstrate how an attacker might take advantage ok weak cookie that is being assigned to the user or if the cookie is kept the same.

This image on the side is a login portal where we are going to carry out the attack & show the problems with weak cookie implementation.

Once we login into the application we intercept the traffic in Burp-Suite to have a look at it and the cookies that are being passed over to authenticate us as a user.

The above image displays the four “Set-Cookie” parameters that are assigned when we try to log in. These four different cookies login, PHPSESSID, show hints, username and the uid. We suspect that the uid is unique for every user. So we go ahead and tamper with the uid to check if we can get access to someone else’s account.

To capture the value of the cookie we use the Cookie Manager extension present in the browser and then pass the request. We change our “uid” from 24 to 12, as shown below.

As soon as we modify the cookie value we can see that we have carried out an account takeover attack as we get access to the other user’s account.

The reason why this attack went through was that the PHPSESSID wasn’t modified at all before and after the user logged-in making the “uid” the only deciding factor for identifying which user has just signed-in to their account. As we can see above that is easily manipulated allowing the account takeover.

To avoid something like this from happening we need to re-assign the cookie after the login attempt and need to keep in mind that the cookie must be unique as well. Here is an idea of how you could do the following.

// Issue is same session object is being used so get current session
HttpSession before_login = request.getSession();
//Invalidate that session
//Generate a new session, new JSESSIONID
HttpSession after_login = request .getSession(true);

The above code is used to change SESSIONID cookie before and after login.

3. User Enumeration via Web Service

The problem of enumeration is a pretty serious deal as it lets the attacker figure out the usernames/email ids of users that are present on the application and the following detail can be later on used for brute force attacks.

We carry this attack on Burp-Suite using the Widsler extension and utilising the “getuser” functionality of it. So, we try to collect the response from the system when we enter the valid username and then we enter a random string which isn’t a username and check for the response then. We can see the respective response in the images below.

The image above is a request and response that we received when the user with a certain username does not exist. We sent the request query in the repeater to check the response.

The image above is a request and response that we received for the condition where the user did exist. We sent the request query in the repeater to check the response and got a different response back this time. This gave us the idea that we can enumerate users based on the response that we receive back.

So, we pass the request in the intruder tab and then carry out a brute force to check for various users those who utilise the application.

The major problem here is that developers are putting too many details in the response query. As in this attack, we can see that because of too much information in the response we could figure out that which of the users with corresponding usernames existed and which of them did not. We need to take some standardised message so that the attacker could not just figure out using some simple enumeration technique.

4. Brute Force attack

This is the next stage attack that is carried out once the attacker has enumerated the users and their usernames via the previous method.

The image beside displays the login page where we have already enumerated the users and need to carry out the brute force attack to know the login credentials of those users.

So, when we attempt to login we intercept the traffic in Burp-Suite and capture the request packet and send it over to the intruder.

Now, that we have the usernames already enumerated we carry out the hit and try, brute force attack. We obtain a group of common password from the internet and run our attack to figure out the corresponding passwords.

Brute Force kind of attack must never be allowed under any circumstance. Account lockout functionality should always be present as it saves the application from being brute-forced and spewing out user credentials. Brute force can also be countered by allowing users not to use dictionary words, use passwords of certain lengths of better ask them to use pass-phrase. The passwords of the users should always be hashed before being stored, the usage of salt with the hash is incredibly important as well.


We can take the following precautions and keep these mental notes while trying to battle the Broken Auth & Session Management issues.

Broken Authentication

Unrevealing error/success messages. Never hard code credential's Password policy enforcement ( ageing, strength, hashes with salts )

Session Management

Unpredictability in tokens ( i.e. secure randomness )Expiration policies, login/logout resetsUse of strong EncryptionComplex Cookie Security

Read my other article regarding “ Secure Coding Practises ”

~ Injection Attacks —

~ Cross-Site Scripting —

If you enjoyed it please do clap & let’s collaborate. Get, Set, Hack!

Website : | Donate :

Telegram :

Twitter :

LinkedIn :

E-mail : [email protected]

8 views0 comments

Recent Posts

See All