Auto-Bypass

What is it

Imagine a house with a big door and lock so that ONLY people who have a key can get in. Now stretch your imagination a wee bit more and imagine a big hole near the gate, slightly hidden so that it is not visible to everyone. An intruder (who knows where to look) can easily come in through the hole without having to worry about getting challenged by the door and the lock.

This is Authentication bypass in a nutshell!

Generally every application (web or mobile) that has any user-specific data / space has an authentication mechanism that tries to ensure that not everyone can access its data. This basically begs the question – “Are you who you say you are?” Critical information can become available to an attacker whose identity cannot be verified meaning someone who did not enter via the door.

How serious is it

Authentication bypass vulnerabilities are very critical as they offer an easy way to get inside an application / system / network without too much effort. Why would someone spend time trying to break the application when he/she can get inside the application without trying other time consuming efforts (like brute force hacking to identify passwords)

The impact of someone gaining access to your application / system through authentication bypass may result in the malicious user

  • Gaining access to data contained in your system (loss of Confidentiality)
  • Stealing data (loss of Availability)
  • Modifying data (loss of Integrity) since authentication mechanisms are usually tied to authorization rules as well

The amount of data an attacker can retrieve depends on multiple factors like his creative skills, system design and vulnerabilities in the application’s authentication system.

How to prevent Sanitize User Input Never generate SQL by directly using user inputs. Attacks like Cross Site Scripting use this vulnerability to insert and execute malicious code on the applications. A better idea is to not trust any user input and sanitize it. Every language worth its salt has some sanitization library in place. OWASP ESAPI (The OWASP Enterprise Security API) libraries are also available for all major languages and could be used.

Use Parameterized Queries

Most platforms like .Net and Java support parameterized queries to generate dynamic SQL. A parameter input is mostly treated as a literal value and not treated as dynamic/executable code.

Use Database Functions/Stored Procedures

Stored procedures are a better way to handle SQL functions. However special importance needs to be put onto their usage as parameterization here would jeopardize the efforts to prevent SQL injection. Parameterized stored procedures are equivalent to having no input sanitization and could still result in SQL injection.

Use Web Application Firewall

Use a WAF to create a protection shield without any change in existing applications. A web application firewall will help you identify & stop any attacks (Note that they may need to be configured properly in order to provide maximum value).

Use Least Privilege Access

Limit access to data by implementing techniques such as Role Based Access Control (RBAC). Do not allow every user to be able to run all queries as this could result in abuse of privileges.

Exception Handling

Improper exception handling will not allow an application to fail gracefully. This could also result in revealing crucial information post-crash. A malicious user can tweak certain queries in order to inject them in the application.

Avoid Obvious Names

Attackers also resort to guessing crucial information labels (Ex. Database names, table names, table prefixes, user IDs, passwords etc.). Change all default values while setting up the system including credentials and configuration settings.