Network connection security has always been important. There are several session management methods, each with their own vulnerabilities and ways to deal with them. In this article, we will take a look at the Broken Authentication (Broken Authentication and Session Management) vulnerability, which is on the OWASP top 10 list.
Common session attacks
Authentication tokens are stored on both the front-end and back-end and are often sent over the network. As such, they are vulnerable to many types of attacks:
- Man-in-the-middle attack
- Stealing OAuth tokens
- to CSRF;
- access the database / file system;
- fix the session;
- brute force attacks;
- social engineering/ physical access.
These attacks may seem unlikely, but it is important to take session security seriously and take appropriate action.
The web application uses session cookies to distinguish one user from another. After you enter your username, password and the application authorizes you, it is stored in a special identifier (session token), which the browser then presents to the server with every request for the web page. This is how the web application immediately recognizes that you are.
If your identifier is stolen by an intruder and the system does not apply checks, for example checking the IP address of the session or multiple connections in one session, the intruder can access the system with the rights of your account. And if this is an internet bank or a payment system, you can easily guess what the consequences of such unauthorized access will be.
Attackers can often try to spoof users using brute force, Weak Passwords and Recovery Process, mismanagement of Session ID, etc.
Likewise, changing the default passwords or using passwords that can be easily guessed cause attackers to infiltrate the application. For example: admin, admin123, password, 123456, 1453, 19811938…
As a precaution, the following steps can be taken:
- Use of strong unique passwords that are not easy to guess. For example; Using @hm3T.123 instead of ahmet.123 will make decryption a hundred thousand times more difficult. For password policies, we must align password length, complexity, and rotation policies, following NIST 800-63 B’s guidelines, section 1.1.
- It should be ensured that default passwords are not used and the first passwords provided by the service must be changed when installing the web service.
- Consecutive Failed Login Attempts should be capped.
- Incorrect login attempts must be logged and examined.
- If possible, CAPTCHA control such as “I am not a robot” should be provided at the entrances.
- For session management, “random session token” should be produced as much as possible and the correct use of “session tokens” and even the selection of appropriate session management applications should be provided.
- Enabling Multi-Factor Authentication (a security system that requires multiple authentication methods)
This seemingly simple Broken Authentication (Broken Authentication and Session Management) vulnerability, which is on the OWASP top 10 list, is easily understood and resolved with the Penetration Test.