Test a SQL-backed authentication bypass

Needs: The injected condition changes the authentication query and the application accepts the resulting account/session

In an authorized disposable lab, preserve the application's quoting and comment syntax

# In an authorized disposable lab, preserve the application's quoting and comment syntax
' OR 1=1-- -
administrator'-- -

Verify → Verify the authenticated identity and protected action, not merely a redirect or a new cookie.

If it fails → Query-shape mismatch or additional checks can block login despite SQLi. Use data extraction or another application path. More detail ↓

If → then

Forms, downloads, exports, account functions or role-specific interfaces → Map functions, roles and normal requests manually
Needs: A normal request baseline and the relevant account/role; authorized accounts for role comparisons
Administrative actions/routes or request methods visible from a lower role → Cross role, function or session authorization boundaries
Needs: The lower-role identity can invoke a protected server-side action without its required authorization
An injectable SELECT renders query results → Extract data through UNION and visible SQL results
Needs: Compatible column count/types, a reflected result position and rights to the requested data

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Test a SQL-backed authentication bypass

USE WHEN: A login/query path has confirmed compatible SQL influence
STARTING ACCESS: A reproducible application request and a controlled input or access-context comparison
RESULT: A verified application authentication transition

Recognize the clue

Use the actual login request already shown to influence SQL, including its real username/password fields and invalid-login control.

curl -sk -i --data-urlencode 'username=USER' --data-urlencode 'password=INVALID_CONTROL' http://TARGET:PORT/login

SYNTHETIC EXAMPLE OUTPUT

Invalid control: login rejected
Mapped handler: username/password query returns a user row

Means: The authentication decision may depend on the injectable query result, creating a bypass candidate.

Confirm: Verify query shape and post-query checks, then independently confirm the resulting session identity/protected action.

After validation: A controlled SQL condition creates a real authenticated session with the intended action: select the bypass route.
Ruled out in this context: The application separately verifies the password after query selection: reject that bypass while retaining other SQL primitives.
Still inconclusive: A redirect or cookie without protected access leaves authentication success unresolved.

Troubleshooting: Query-shape mismatch or additional checks can block login despite SQLi. Use data extraction or another application path.

Additional prerequisite checks

curl -sk -i -c cookies.txt --data-urlencode "username=USER' OR '1'='1'-- -" --data-urlencode 'password=INVALID_CONTROL' http://TARGET:PORT/login

In an authorized disposable lab, preserve the application's quoting and comment syntax:

Verification: identify the resulting account/session and perform a separate authorized request. A redirect or welcome string alone can be misleading.

Why it works

Changing a WHERE clause can return a user row, but the application may perform additional password/account checks. Bypass must be proven by the new session and accessible functionality.

Worked example · hypothetical

Observation: the login query is injectable. Test: compare invalid-password control and bypass request. Illustrative output: a new authenticated session can read a protected profile. Interpretation: confirm which identity was selected and enumerate its application rights.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗