Declaration: This article is compiled and translated by Bypass for security research and learning purposes only.
Article source: medium.com/bugbountywr…
How to write secure code? Protect yourself from broken authentication and session management!
Need a security code?
I’ve been working on secure coding practices and trying to learn as much as I can about the basics. Over the past few years, I have come to realize the damage that a small leak can cause in the lives of ordinary people. Cyberattacks like WannaCry and Petya ransomware are fairly new to the minds of several people who have suffered their causes.
Researchers could still find another very serious bug in web applications and other areas. Unless programmers themselves are aware of the code they are writing, this trend will not decline. The code should not only be able to do what it’s supposed to do, but it should also be able to resist any malicious loads and attack scenarios. The best way to achieve this is to be able to build synergies and help each other between the coding and security communities.
Let’s dig!
So, this particular article, “How to Write Secure Code?” Focus on authentication and session management issues.
Authentication and session management-related application functions have security flaws that allow an attacker to destroy passwords, keys, session tokens or take advantage of other implementation flaws to assume the identity of another user.
In this article, I’ll cover several different types of attacks and methods that you can use to prevent them: –
1. Hardcode login credentials
Hard-coding login credentials is one of the biggest mistakes a programmer can make, because it’s just as good as providing a hacker with credentials on a silver disk. Sensitive data should never be hard-coded.
Insecure codes – hard-coded credit cards
The code above is an example where the login credentials are hard-coded in code written by the programmer.
While the following code is an example, where the credentials are not hard-coded in the program, making it more secure than the hard-coded indices of credit cards.
Security code – Credit is not hard-coded
This small difference can have a huge impact on the security of your application.
2. The cookies
Cookie operations are becoming one of the most dangerous attacks today as more and more authentication processes are performed by examining the cookie details provided by the user.
Attackers are looking for ways to break and figure out how web applications assign cookies so they can manipulate them and structure them like other users do account takeovers.
Let me demonstrate how an attacker can take advantage of weak cookies assigned to users or leave cookies unchanged.
The image here is of a login portal that we are going to attack and show the problem of weak cookie implementation.
Once we are logged into the application, we intercept the traffic in the Burp-Suite to view it and the cookies passed to the user to authenticate us.
Cookie details
The figure above shows the four “set-cookie” parameters assigned when we tried to log in. These four different cookies login, PHPSESSID, display prompt, username and UID. We suspect that uid is unique to each user. So we continue to tamper with the UID to see if we can access someone else’s account.
Modify the cookie
To capture the value of the cookie, we use the cookie Manager extension that exists in the browser and then pass the request. We changed “uid” from 24 to 12, as shown below.
Modified cookies
Once we change the cookie value, we can see that we have performed an account takeover attack when we access another user’s account.
The reason for this experience is that the PHPSESSID is not modified at all before and after a user logs in, so the “UID” is the sole determinant of which user has just logged in to their account. As we saw above, it is easy to manipulate, allowing the account to take over.
To avoid this, we need to reassign cookies after a login attempt, and we need to remember that cookies must also be unique. Here are some ideas on how to do the following.
// The problem is that the same session object is being used, so get the current session HttpSession before_login = request.getSession (); // Invalidate the session before_login.invalidate (); // Create a new session with a new JSESSIONID HttpSession after_login = request.getSession (true);Copy the codeThe above code is used to change the SESSIONID cookie before and after login.
3. Enumerate users using Web services
Enumeration is a serious problem because it allows an attacker to figure out the user name/email ID of the user that exists in the application, details that can be used later in a violent attack.
We use the Widsler extension and use its “getUser” feature to do this against Burp-Suite. So, when we enter a valid user name, we try to collect the response from the system, and then we enter a random string that is not a user name, and then we check the response. We can see the corresponding response in the image below.
User does not exist
The image above is of the request and response we receive when a user with a particular username does not exist. We sent a request query in the forwarder to check the response.
Users do exist
The above image is the request and response we received for the condition that the user actually exists. We sent a request query in the forwarder to check the response and got a different response this time. This gave us the idea that we could enumerate users based on the responses we received.
Therefore, we pass the request in the intruder TAB, and then perform brute force to check the individual users using the application.
Enumerated user name
The main problem here is that the developers actually put too much detail into the response query. As we can clearly see in this attack, because there is so much information in the response, we can figure out which users have the appropriate username and which do not. We need to make some standardized messages so that attackers can’t just use some simple enumeration technique.
4. Violent attacks
This is the next stage of the attack that the attacker performs after enumerating users and their usernames in the previous method.
The image next to it shows that we have enumerated login pages for users whose login credentials we would need to perform a brute force attack on.
So when we try to log in, we intercept the traffic in the Burp-Suite and capture the request packet and send it to the intruder.
Request query
Now that we have enumerated the user names, we perform hit and try, brute force attacks. We take a set of commonly used passwords from the Internet and run our attack to find the corresponding passwords.
A brute-force attack via burp-Suite
Under no circumstances should violent attacks be allowed. Account locking should always be present, as it prevents the application from brute force cracking and spitting out user credentials. Brute force can also be offset by allowing users to avoid dictionary words and use passwords of a certain length to better require them to use passwords. The user’s password should always be hashed before storage, and it is also important to use hashed salt.
Security defense
We can take the following precautions and preserve these mental records as we try to combat authentication and session management issues.
Authentication failed
- An error/success message is displayed
- Never hard-code credentials
- Password policy enforcement (Mature, strong, salt hashing)
Session management
- Unpredictability of tokens (i.e., safe randomness)
- Expiration policy, login/logout reset
- Use strong encryption
- Sophisticated Cookie security