A2: Broken Authentication 2017 OWASP

What is authentication and session management

Authentication describes the procedure to verify one's identity. On most websites that is encountered in the form of a username and password combination which is needed to log in. When dealing with an API this can also be a token often referred to as an access token. Session management on the other hand comes into play when we are successfully authenticated. Upon login a unique session key is generated most often in the form of a cookie or a JWT which is short for json web token. This unique key ensures that our logged in session is held upright as we browse the application so we don’t have to re-authenticate each time we switch the endpoint.

What is broken authentication

As stated in the introduction, broken authentication denotes that there is an issue with the authentication or the way that the session is handled. This isn’t limited to the login functionality of an application but can also be of great impact when it comes to API security. Causes of this can be leaked session tokens that can be found in the url. Also weak or nonexistent encryption of communication can be a cause. As well as exposed or leaked credentials which weren’t changed after a data breach.

Attack scenarios

• Man in the middle attacks

Like mentioned earlier upon a successful login a unique session key is created. If there is no encryption of the traffic and the key gets transferred in plain then an attacker who is sniffing the traffic can capture that key and steal the users session. This is also referred to as session hijacking.

• Credential stuffing / Bruteforce

In case there is no account lockout policy in place or some sort of rate limiting this can lead to an attacker being able to bruteforce passwords for certain accounts. Furthermore this attack has a better chance of success when there is no WAF (web application firewall) in place which inspects and filters incoming traffic.

• No session timeouts

If the session of a logged in user doesn’t automatically expire after a certain time this can be problematic. If someone for example uses a computer at their university and just closes the web browser instead of properly logging out of their account this can have severe consequences. Now the attacker can just use the same browser an hour later and the user will still be logged in if session timeout isn’t implemented properly.

Examples

An example with a big impact can be found in CVE-2021-38513 where netgear devices have been found to contain a critical vulnerability as the authentication can be bypassed. The method of attack is still unknown but the damage rising from this vulnerability can be devastating which is why they are advising anyone on older versions of the firmware to upgrade to the latest version. More information can be found on the CVE page itself and the exploit itself will be filled in when it is made public. https://www.cvedetails.com/cve/CVE-2021-38513/

For our second example we are going to look at a company named Circutor which provides several products related to power management and home automation. In one of their products, an authentication bypass was found on the firmware related to mishandling of cookies. It is super important to not only implement authentication controls but also to use them effectively. https://www.cvedetails.com/cve/CVE-2021-33842/ 

‍

How can I prevent broken authentication

There are several things that can be done in order to prevent such flaws.

• Strict password policy

By using a strict password policy one can drastically decrease the success of a bruteforce attack and furthermore eliminate guessable credentials. A good starting point would be to only allow passwords with 12+ characters which require numbers, symbols, upper- and lowercase characters.

• Encryption

All traffic should be encrypted. Thus an attacker can’t sniff password nor session keys over the wire and has no chance with a man in the middle attack. Furthermore the encryption method should always be as strong as possible, since it’s fairly easy to break weak encryption.

• No excessive information

Upon a failed login there must not be any information revealed. For example telling that the password for the username is wrong gives the attacker proof that that user exists. A generic message should be used instead. Something like “Failed Login!”.

‍

‍

Preventive measures

Other preventive measures would be forcing the user to use two factor authentication. This way even if a password gets breached it’s no use to the attacker as long as he can’t get the second factor. We can also take some steps to increase the security of our API. For one the access token used by the API must never be guessable nor brute forceable. Additionally a WAF should be set up so that it can filter the incoming traffic and prevent the forging of session keys. On top of that cross site scripting needs to be prevented as it can be used to steal session keys. There are also options to implement breached password protections. So that those passwords that have been breached can’t be chosen to secure an account, which itself increases the security a lot in defence against this issue type from the top 10 OWASP vulnerabilities.