Link Search Menu Expand Document

Broken Authentication

Play SecureFlag Play Labs on this vulnerability with SecureFlag!

  1. Broken Authentication
    1. Description
    2. Impact
    3. Scenarios
    4. Prevention
    5. Testing

image

Description

Broken Authentication is an application security risk that can allow malicious actors to compromise keys, passwords, and session tokens, potentially leading to further exploitation of users’ identities and in the worst case, complete control over the system.

In essence, the vulnerability boils down to an attacker being able to bypass the authentication mechanism of the vulnerable application due to poor configuration, logic errors, or bugs in the software.

This class of vulnerability can affect any kind of software that implements access control to pretty much any application, including databases, network infrastructure applications, and web applications.

As with many of the risks listed on the OWASP Top 10, authentication vulnerabilities are not a new security topic, and often a malicious actor does not have to be highly technical to bypass poorly implemented identity and access controls… it makes an attackers job even easier given these controls are often entirely non-existent! As such, there should be no surprise to learn that it has been categorized as a critical risk affecting web applications on the OWASP Top 10 since 2013.

Impact

A successful attack can result in a malicious attacker gaining complete access to all data in the web application, assuming administrator rights, and compromising the confidentiality, integrity, and availability of the application.

Scenarios

There are a variety of different Broken Authentication instances that attackers can leverage depending on the vulnerability within the implementation of the identity or access control. Some methods of exploitation and potential weaknesses include:

  • Functionalities requiring authentication lack mechanisms or implement insufficient protections.
  • Broken object-level protection mechanisms allow unauthenticated users to access private resources.
  • The use of dictionary-based attacks or credential reuse on applications that permit automated attacks.
  • The application permits the use of weak passwords, such as “password123” or “123456”.
  • The application doesn’t encrypt or weakly encrypts passwords.

Prevention

The utilization of updated security controls that ensure user identity, authentication, and session management is crucial if one is to prevent authentication attacks successfully. Yet very often, a Broken Authentication is the result of logical errors or oversights. Since Broken Authentication as a category includes so many attack vectors, there are plenty of potential weaknesses to be aware of.

For instance, applications should be checked for, and appropriately adjusted/implemented in, the following ways:

  • Implement session ID rotation following successful logins and ensure rules around session ID invalidation during logout or inactivity are correctly implemented.
  • Test authentication correctness in addition to the functional aspects of the application.
  • Implement an effective password policy that disallows the use of weak or overused/common passwords.
  • Implement password retry lockout.
  • Implement perimeter access control security such as IP allow-list and use of bastion hosts.

Testing

Verify that APIs implement consistent authentication security control strength, such that there are no weaker alternatives per the risk of the application.


Table of contents