How to Bypass Authentication [Multiple Ways]
Let’s talk about a few ways to bypass authentication. I’m not going to tell you from the top of my head, but use credible resources such as OWASP, and I’m also gonna link to a great resource at the end.
First off, in the Web Security Testing Guide or WSTG here, we’ve got 4 ways that can be used to bypass the authentication schema in web applications, and these are:
Direct page request (forced browsing)
Parameter modification
Session ID prediction
SQL injection
Let’s talk about each of them.
Direct page request - This is also known as forced browsing, and is exactly what you’re thinking it is. So, let’s say you have a protected page, such as an admin page, which you normally access after authentication via a login panel. When we’re talking about forced browsing, the attacker seeks to exploit flaws in the application’s authentication process by accessing functionality or data that is not properly protected by authentication controls.
For example, an attacker may be able to bypass the login page of an application and access restricted content or functionality by directly accessing a URL that is not protected by authentication. In this case, by going directly to /admin via the URL.
Parameter modification - This example is very explicitly explained by OWASP in that the issue appears when the application verifies successful authentication via fixed parameter, such as:
“authenticated” = “yes”
“logged_in” = true
“is_admin” = true
If the attacker is able to manipulate these parameters by tampering with the request itself, the consequences can be devastating.
Session ID prediction - The majority of web apps use IDs in different shapes or forms, such as cookies or tokens, to authenticate requests. If these IDs are predictable, an attacker could guess a valid ID, therefore manipulate the application to their desire. From a personal experience, and based on the 80+ pentests and appsec assessments I’ve done in 2022 alone, this scenario is not very far from reality. I’ve seen session IDs, tokens, and cookies of short length, which with a little bit of effort could be guessed via an algorithmic analysis. And one good way to actually test this is using BurpSuite’s sequencer.
SQL Injection - This method has been widely explained throughout the years all over the Internet and I’m only gonna briefly say that you can often bypass authentication by tricking the database so to speak via unsanitized input fields using payloads such as:
admin' or '1'='1
More payloads here. Or you can simply use the Intruder feature in BurpSuite which also has a default payload list for SQL Injection attacks.
Now, alongside the 4 mentioned methods from OWASP, I’d also add two more:
Authentication Bypass Using Default Accounts – In this method, the attacker takes advantage of weak or easily guessed default credentials to gain unauthorized access to the application. For example, many applications ship with default accounts that have well-known usernames and passwords (e.g., “admin”/“password”). Attackers can exploit these accounts to gain access to sensitive functionality or data within the application.
Authentication Bypass Using Weaknesses in Password Change or Reset Mechanisms – For example, many applications allow users to change their passwords without requiring the current password for verification. An attacker could exploit this weakness by changing a user’s password without their knowledge and then gaining access to sensitive functionality or data as that user. Again, as strange as it may sound, in 2022, you can still see applications that do not implement proper password reset mechanisms.
So, we’ve seen 6 ways that you as a penetration tester or appsec specialist can use to test in your projects and engagements. And as promised, I’d also like to mention the wonderful Gitbook called Hacktricks, which is linked below, and it gives you many more avenues to test against authentication bypass.
References:
If you want to get updates on stuff I’m doing: