SQL Injection Authentication Bypass

The login form is the first place anyone tries SQL injection, because the payoff is immediate: skip the password entirely. If the username and password are concatenated into a query, you can rewrite the condition that decides whether you are let in.

Why login forms are vulnerable

A naive login looks up a matching row:

SELECT * FROM users WHERE username = 'INPUT' AND password = 'INPUT'

If a row comes back, you are in. The flaw is that both inputs are pasted into the string. Control either one and you control the WHERE clause that guards the door. Confirm it the usual way: drop a single quote into the username and look for a database error or a changed response.

The ' OR 1=1-- - family and why it works

The classic payload makes the condition true no matter what:

' OR 1=1-- -

The query becomes:

SELECT * FROM users WHERE username = '' OR 1=1-- -' AND password = '...'

Your quote closes the empty username, OR 1=1 makes the WHERE match every row, and -- - comments out the rest, including the password check. The database returns a user and the app logs you in. Variants that handle different quoting:

' OR 1=1 LIMIT 1-- -
') OR ('1'='1'-- -
" OR ""="

Commenting out the password check

The real work is often the comment. Everything after -- - is ignored, so the AND password = '...' clause never runs. Use # on MySQL if the dash form is filtered, and remember the space (and trailing dash) after -- so the comment is recognized.

Logging in as a specific user

OR 1=1 returns the first matching row, which may not be the admin. To land on a specific account, inject into the username and comment out the password:

admin'-- -

SELECT * FROM users WHERE username = 'admin'-- -' AND password = '...'

The query now asks only for the row where username = 'admin' and ignores the password. You are logged in as the administrator.

When it fails

This does not always work, and knowing why saves time:

• Hashed lookups. If the app fetches the user by name, then compares a hash in code, injecting into the password field does nothing useful. Target the username instead.
• ORMs and prepared statements. When the query is parameterized, your quote is just data. No bypass.
• Separate queries. Some apps select the user, then check the password in application logic, which changes which field is injectable.

Fixing it

Use parameterized queries for both fields so input can never alter the clause. Look the user up by username, then verify a securely hashed password in code. Never build the authentication query by concatenation.

Ready to try it? Sign up free and walk straight through a real login.