Understanding potential vulnerabilities in authentication mechanisms
Despite the fact that authentication is simply one of the components involved in testing an application as a whole, it is one of the most important because of the strong correlation between authentication and security. Being able to bypass an authentication system can offer an attacker access to a bigger attack surface, in addition to granting access to sensitive information.
It is essential to determine what an authentication system is. An authentication system, which is distinct from authorization, is a feature of an application that verifies that the user accessing the system is who he claims to be. An authorization system is a feature of an application that verifies that the user has permission to perform the task at hand.
We need to know what kinds of authentication mechanisms an application can employ. We’ll look at three of the most common ones in web applications:
- Single factor login (password based login)
- Single Sign On
- Multi factor login (password based + confirm with other device)
Single factor login (or password based login)
The most common type of web application login is single-factor login, sometimes known as password-based login. The user has to enter a username or email address and a password; the application checks to see if this information is stored in the system; if it is, the application usually redirects the user with a session cookie; and if any of this information is incorrect, the application provides an error screen.
We already have some potential vulnerabilities in the stage where the user provides login and password to the application. As in the case of the application failing to set a request limit or allowing users to use a password that is too easy to guess. These are security flaws that make it simple for an attacker to bruteforce their way into a user’s account. To prevent this type of attack, the application should require the user to enter a strong password and set a rate limit to prevent a single user from sending too many requests in a short period of time. Many applications utilize a WAF to set a rate limit.
Lab: Broken brute-force protection, IP block | Web Security Academy (portswigger.net)
It’s also possible that the application accepts multiple credential attempts in the same request because of a misconfiguration or incorrect validation. Even if the application has a request limit, this can make a bruteforce possible.
The application should also avoid using any service’s default credentials. If there are any services in the application that haven’t changed their credentials, the attacker will be able to log in using them. If the application uses a service that maintains default credentials, it’s worth attempting to gain access using those credentials.
Testing for Default Credentials- OWASP
An application can check whether the credentials entered by the user match any of those stored on the system in a few ways. Of course, other vulnerabilities may exist according on how this is done. In the case of an application that uses a database, injection may be possible depending on the database type. If the application employs SQL, SQL injection; if the application uses NoSQL, NoSQL injection.
When an application fails to properly treat user inputs and uses them in database queries, injections might occur.
An example of SQL Injection-vulnerable code is as follows:
Using SQL Injection to Bypass Authentication — PortSwigger
NOSQL INJECTION FUN WITH OBJECTS AND ARRAYS
If the application is written in PHP and is older than PHP 8, when the user submits JSON data, a type juggling vulnerability can exist. This vulnerability occurs when the user input is compared using a loose comparison (==) rather than a strict comparison (===). The user can control the type of their input by submitting a JSON parameter value as an integer without quotes, which the program will treat as an INT instead of a string. If the application implements loose comparison, the table below displays some comparisons that can be used.
When we compare 0 to a string, the output is true, as seen in the table above. As demonstrated in the image below, this can be utilized to bypass login.
PHPMagicTricks-TypeJuggling.pdf (owasp.org)
PHP Juggling type and magic hashes
Following the validation, the server sends the response to the user. Some vulnerabilities can happen as a result of this response. It is possible for an attacker to enumerate the users on a system if the application responds differently when a valid user and an invalid user are sent.
Lab: Username enumeration via different responses | Web Security Academy (portswigger.net)
This response potentially reveal more sensitive information about the app or its users.
OWASP Top 10 — Sensitive Data Exposure — Code Maze (code-maze.com)
OWASP Top Ten 2017 | A3:2017-Sensitive Data Exposure | OWASP Foundation
Another possibility is that the application allows you to access pages that require logging in based strictly on the response code. If the application responds with a 401, but you use a proxy and modify the response code to 200 OK, the application can display the page as if you were signed in.
Authentication Bypass via Response Manipulation — Hackerone Program — Professor — YouTube
https://medium.com/@MAALP/authentication-bypass-using-response-manipulation-6c33eb1257ac
If you forget your password, most authentication systems allow you to reset it. This function is interesting to investigate because you might be able to set another user’s password using a parameter that the application sets predictably or unexpectedly.
Lab: Password reset broken logic | Web Security Academy (portswigger.net)
Single Sign On
How it works
Single Sign On (SSO) is an authentication solution that allows users to use the same login credentials for multiple applications. The application’s trust in the identity provider is the basis of this authentication service.In general, the SSO login flow works like this:
- The user accesses in to the application he wishes to visit.
- The application redirects the user to the IdP page with some parameters.
- The user enters his credentials into the IdP.
- With a token that validates the user’s login, the IdP redirects the user back to the application.
- After validating the token, the application logs the user in.
The following parameters are usually used in the request from the application redirecting to the IdP:
- The parameter “client_id” specifies to the IdP which application the user is accessing.
- The parameter “redirect_uri” sets the url to which the IdP will redirect the user after he logs in.
- The “scope” parameter tells the IdP what information the application is allowed to read from the user.
- The parameter “response_type” tells the IdP which flow and parameters will be used.
- The “state” parameter is a hash that is given from the application to the IdP and then validated; it works as a CSRF token to prevent CSRF attacks.
The IdP receives these parameters, the user logs in, and the IdP redirects the user to the “redirect uri” with the user’s state and token, which the application validates before giving the user the session cookie.
Potential Vulnerabilities
We have some vulnerabilities if the arguments sent to the IdP are not validated or are validated incorrectly. We have an open-redirect in the case of “redirect uri” not being validated. We may be vulnerable to CSRF attacks if the application does not validate the “state.” We have account takeover if the application does not validate either of these two parameters correctly, because it will be possible to create a link with “redirect uri” to an attacker’s site, and when the user logs in, it will send the token to the attacker’s site, which will be able to use this token to log in, because the application does not validate the request’s integrity (what should be done with the “state”).
Lab: OAuth account hijacking via redirect_uri
Stealing OAuth Tokens With Open Redirects | Okta Security
Many applications allow you to log in with multiple IdPs, allowing you to authenticate with multiple accounts like Google, GitHub, and Twitter. It’s possible that the application implements this incorrectly, resulting in a Multi-IdP misconfiguration. A pre-account takeover is possible if Multi-IdP is implemented incorrectly. This happens if the application allows you to log in with both your email and password, as well as your email’s IdP. So, if an attacker creates an account with an email example@gmail.com and a password, but also allows you to log in with Google, but fails to make the necessary validations, the account that logged in with Google may end up giving access to the attacker who created the account with the same email but with a password.
OAuth to Account takeover — HackTricks
OAuth 2.0 authentication vulnerabilities
Two Factor Authentication
How it works
Most 2-factor validation applications work similarly to password-based login applications. The difference is that these typically include a second verification step in which the user confirms a token on a device such as a cell phone, which is typically accomplished through app or SMS.
Potential vulnerabilities
The lack of validation of the token being sent is one of the most critical vulnerabilities.
The lack of validation of the token being sent is one of the most serious flaws. In some scenarios, the application requests the user to enter their user name and password, and if they are valid, the user is redirected to a screen where they can validate their 2-factor token. However, before completing this confirmation step, the user may be able to view the restricted pages for logged-in users.
Lab: 2FA simple bypass | Web Security Academy (portswigger.net)
Bypassing the Protections — MFA Bypass Techniques for the Win | Cobalt
If the application does not have a ratelimit, the two-step login is vulnerable to bruteforce attacks, exactly like a single-factor login. This is much worse if the token is predictable, such as always being six numbers, because the attacker can test all combinations until the token is valid.
Lab: 2FA bypass using a brute-force attack
Vulnerabilities in Keep Logged functionality
There are vulnerabilities that occur after a user has already logged in and can occur regardless of the type of login.
It’s important discussing the vulnerabilities that may exist in the session cookie that the application sets once the user logs in if the cookie is a JWT. JWT tokens are made up of three pieces, each of which is separated by a “.” and encoded in base64. Header, payload, and signature are the three sections. The vulnerabilities that can occur in a JWT-enabled application are related to the possibility that the user can modify the header and payload while the application still validates the cookie. There are 2 techniques for it. One is to bruteforce the JWT’s secret; if the JWT is signed with a weak secret, the attacker may be able to discover it using bruteforce and use it to modify and validate their JWT. Another possibility is that the application does not validate the signature, in which case you would not need the secret to create a valid JWT and could simply use the original jwt’s third part instead.
JWT attacks | Web Security Academy (portswigger.net)
Some applications allow you to stay logged in even after you leave the site, which can be dangerous depending on how it’s done. Some applications use a token, which, if discovered, allows attackers to gain control of an account. Other programs may rely on a header that informs them of the user’s IP address; if this is the case, the attacker may attempt account takeover by manipulating this header.
