Broken Authentication

What is Authentication

Authentication is the process of verifying the identity of a user or system before granting access to protected resources. This typically involves checking credentials—such as usernames, passwords, tokens, or biometric data—against a trusted source (e.g., a database) to ensure only authorized entities can access the application.

Attacks on Authentication

Attacks on authentication aim to bypass or compromise the verification process, giving attackers unauthorized access. Common tactics include enumerating valid users, brute-forcing passwords, abusing password reset mechanisms, and exploiting weak session token generation.

Enumerating Users

User enumeration involves discovering valid usernames by analyzing subtle differences in server responses or error messages. For instance, a login form might return:

• “Invalid password” for an existing user with a wrong password
• “User not found” for a non-existent user

Such discrepancies allow attackers to identify which usernames are valid. Armed with a list of valid usernames, attackers can proceed to brute-force passwords or launch more targeted attacks.

Brute-Forcing Passwords

Brute-forcing passwords involves systematically attempting a large number of password combinations until the correct one is found. Attackers often use automated tools like Hydra, Medusa, or Burp Suite Intruder to expedite this process.

# Example Hydra command
hydra -L users.txt -P passwords.txt http://target.com/login

Mitigations typically include:

• Account lockouts after repeated failures
• CAPTCHAs
• Increasing time delays between failed attempts

Brute-Forcing Password Reset Tokens

Password reset tokens are intended to be short-lived and unpredictable. However, if these tokens are generated via weak or predictable methods, attackers can brute-force them:

1. Identify the reset token parameter (e.g., token in ?token=XYZ123).
2. Write a script to iterate through potential tokens until the correct one is found.
3. Once found, the attacker can reset the victim’s password without authorization.

Brute-Forcing 2FA Codes

Two-factor authentication (2FA) requires a second verification step, often a six-digit code. Without rate limiting, an attacker can brute-force all possible codes. For a 6-digit code, there are 1,000,000 combinations. Proper lockout policies and rate limiting are critical to prevent this attack.

Bypass 2FA

Sometimes 2FA can be bypassed or brute-forced if the application does not implement proper rate limiting or has weak 2FA logic. For instance, if a TOTP (Time-Based One-Time Password) code is expected, an attacker might fuzz the code parameter:

# Generate potential 4-digit codes
seq -w 0 9999 > tokens.txt

# Use ffuf to test each code
ffuf -w ./tokens.txt -u http://bf_2fa.htb/2fa.php -X POST \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -b "PHPSESSID=fpfcm5b8dh1ibfa7idg0he7l93" \
     -d "otp=FUZZ" -fr "Invalid 2FA Code"

If the server does not implement a lockout or a robust rate limit, an attacker could discover the correct 2FA code and bypass this security measure.

Weak Brute-Force Protection

Rate Limiting

Rate limiting aims to restrict how many login attempts can be made within a certain time. However, attackers can sometimes circumvent it by setting arbitrary HTTP headers—like X-Forwarded-For—to appear as though each request originates from a different IP address. This technique bypasses naive IP-based rate limiting.

CAPTCHAs

CAPTCHAs are designed to distinguish human users from automated scripts. However, if the CAPTCHA solution is provided in the server’s response or if the attacker employs automated CAPTCHA-solving tools (including AI-driven solutions), CAPTCHAs can be bypassed or automatically solved.

Password Reset Flaws

Some applications rely on security questions or other easily brute-forced mechanisms for password resets. Attackers can fuzz these questions if they are not properly rate-limited or if the questions are too simple (e.g., “What is your pet’s name?”). By systematically guessing answers, attackers might reset the user’s password.

Default Credentials

Many systems are deployed with default credentials that are widely documented (e.g., admin:admin). If not changed during setup, these credentials present an easy attack vector. Attackers routinely test well-known default logins for common services or hardware.

Vulnerable Password Reset

Weaknesses in the password reset process can allow attackers to reset user passwords without adequate verification. Common pitfalls include:

• Predictable or weak reset tokens
• Missing verification steps (e.g., email confirmation or security questions)
• Failure to expire tokens promptly

Authentication Bypass via Direct Access

Sometimes critical resources (like an admin panel) are exposed to the internet without any authentication checks. Simply navigating to a hidden URL might grant administrative privileges if the developer assumed “security through obscurity.”

Example:

http://target.com/admin

If no login is required, anyone can access it.

Authentication Bypass via Parameter Modification

Developers may store access level or role information in user-controllable parameters. Attackers can modify these parameters to escalate privileges or bypass authentication checks.

Example:

http://target.com/dashboard?user=123

Changing user=123 to user=124 might grant access to another user’s dashboard if the application does not verify the user’s identity on the server side.

Attacking Session Tokens

Take the following example of session tokens:

2c0c58b27c71a2ec5bf2b4b6e892b9f9
2c0c58b27c71a2ec5bf2b4546092b9f9
2c0c58b27c71a2ec5bf2b497f592b9f9
2c0c58b27c71a2ec5bf2b48bcf92b9f9
2c0c58b27c71a2ec5bf2b4735e92b9f9

Notice that 28 of the 32 characters are static. The tokens share the prefix 2c0c58b27c71a2ec5bf2b4 and the suffix 92b9f9, leaving only 4 characters of actual randomness. This severely weakens the token, as an attacker only needs to brute-force 4 characters to potentially hijack all active sessions.

In more realistic scenarios, the token might appear random on the surface, but the underlying generation logic can be predictable. Attackers who gain insight into how the token is generated can predict valid tokens and hijack sessions.

Encoded Data in Session Tokens

Sometimes tokens contain encoded or serialized data that can be manipulated:

# Decoding base64
echo -n dXNlcj1odGItc3RkbnQ7cm9sZT11c2Vy | base64 -d
user=htb-stdnt;role=user

An attacker might modify the role:

echo -n 'user=htb-stdnt;role=admin' | base64
dXNlcj1odGItc3RkbnQ7cm9sZT1hZG1pbg==

If the application does not verify the integrity of this data, the attacker can gain elevated privileges by simply replacing the token with the modified version. Similar logic applies to hex-encoded or URL-encoded tokens:

echo -n 'user=htb-stdnt;role=admin' | xxd -p
757365723d6874622d7374646e743b726f6c653d61646d696e

Execution After Redirect (EAR)

An Execution After Redirect (EAR) vulnerability arises when a web application issues an HTTP redirect (usually via a 3xx status code and a Location header) but continues processing the request afterward. Under normal circumstances, developers will typically include a return, die, or exit statement immediately after sending the redirect header to ensure no further code executes. However, if they omit this step, the server can still process the rest of the code—even though the client receives a redirect response.

1. User Accesses a Restricted Function
   Suppose the application checks if a user is logged in. If not, it sends a redirect to the login page:

   if (!isset($_SESSION['user'])) {
       header('Location: login.php');
       // Missing exit/die here
   }
   // Code below still executes!
   

2. Server Processes the Request Anyway
   Because the code continues executing after the redirect, any logic below that redirect check (e.g., creating a user account, deleting data, etc.) may still run—even if the client is told to go elsewhere.
3. Attacker Exploits the Gap
   An attacker can craft a request to a restricted endpoint. The server sets a redirect response but still performs the action (like adding a user or changing a password). From the client perspective, they see a redirect; however, the operation is already completed on the server side.

Reference: For a real-world example and further reading, see this article. It highlights how improper handling of redirects and continued execution of user-supplied data can lead to severe security vulnerabilities.