In a previous post, we covered the code injection security threat in details. In this post, we’re going to dig into the broken authentication vulnerability in web applications, and look at ways to avoid it.
Securing user authentication is a crucial part of making the web application safer. To understand this vulnerability better, let us look into how a typical authentication process looks like:
Now, if there are any flaws in this mechanism, or if the authentication process does not take care of the best practices in its implementation, an attacker can use manual or automatic mediums to try gain access over any account, or in the worst case, control over the system.
While the threat can come in many forms, these are some obvious cases which make the application vulnerable to the attack:
Storing passwords as plain-text. It is never a good idea. Always hash the passwords with salt before storing them, so that even if there is a database breach, the credentials are not exposed. Do not use weak hashes like SHA1 or MD5.
Leaving login page for administrators publicly accessible to all visitors of the website.
Not taking care of automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.
Not taking care of brute force or other automated attacks.
Not checking the password against a list of most common passwords.
Using weak or ineffective credential recovery and forgot-password processes, such as knowledge-based answers, which cannot be made safe.
Exposing Session IDs in the URL. e. g. URL rewriting: http://example.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii
Not rotating session IDs after successful login.
Not properly invalidating session IDs. User sessions or authentication tokens, particularly single sign-on (SSO) tokens, aren’t properly invalidated during logout or a period of inactivity.
As mentioned in a previous post, “it’s going to take a culture change” for organizations to properly address application security”, we shall always stress on having a secure software over working software. Most of the issues mentioned above may seem obvious to you, but these vulnerabilities can still be found in many applications even today.
To keep the application secure from this particular vulnerability, it is important for the developer to be aware of the best practices of website security. The code should be tested thoroughly before it is deployed to production.
Here are some of OWASP’s technical recommendations to make sure your application is safe from these broken authentication vulnerabilities:
Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login.
Session IDs should not be in the URL. IDs should also be securely stored and invalidated after logout, idle, and absolute timeouts.
Wherever possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks.
Do not ship or deploy with any default credentials, particularly for administrator users.
Implement weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst passwords.
Align password length, complexity and rotation policies with NIST 800-63 B’s guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence-based password policies.
Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes. e.g. Authentication failure responses should not indicate which part of the authentication data was incorrect. Instead of “Invalid username” or “Invalid password”, just use “Invalid username and/or password” for both. Error responses must be truly identical in both display and source code.
Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected. The use of lists of known passwords is a common attack. If an application does not implement automated threat or credential stuffing protection, the application can be used as a password oracle to determine if the credentials are valid.