The Login That Didn’t Need a Password

Lab one was a shop filter — I made hidden products appear. This one is sharper. Same bug, bigger prize: I skipped the password entirely and logged in as the administrator.

Two characters did it: '--.

What the bug actually is

When you log in, the app checks your details against a database. It writes a question like this:

SELECT * FROM users WHERE username = 'you' AND password = 'yourpassword'

SELECT * FROM users WHERE username = 'you' AND password = 'yourpassword'

In plain words: "Find a user where the username is you AND the password is yourpassword." If a row comes back, you're in.

Here's the flaw. The username came from me — the login form. If the app drops my text straight into that question, I can rewrite the question. And SQL has a comment symbol — -- — that means "ignore everything after this." If I can comment out the password check, the database stops checking the password at all.

What I Noticed

I started by just looking at the site.

I opened it in Burp Suite (a proxy tool that sits between the browser and the site, recording every request). I used Burp's built-in browser so all traffic flows through it.

The homepage was a shop, but one link at the top stood out: My account. I clicked it. A login form — username and password.

A login form is a database lookup waiting to happen. That was my target.

Before touching it, I read the page source in Burp. One detail mattered:

A CSRF token — a one-time random value the form sends to prove the request came from the real page. This told me my login request had three fields, not two: csrf, username, password. I'd have to keep that token intact or the server would reject me before my injection ever reached the database.

The action, step by step

Step 1 — Capture the real login request.

I typed junk into the form — username test, password test — and submitted it with Burp's Intercept on. Burp paused the request and showed me the body:

There it was. Three fields, exactly as the source promised.

Step 2 — Inject into the username.

I changed only the username value, leaving the csrf and password alone:

What this does to the database question:

SELECT * FROM users WHERE username = 'administrator'--' AND password = 'gfghntyhnytjhngh'

SELECT * FROM users WHERE username = 'administrator'--' AND password = 'gfghntyhnytjhngh'

Read it slowly:

• ' closes the administrator text.
• -- comments out everything after it — so AND password = 'test' is ignored, gone.
• The database checks only username = 'administrator'. No password check.

I forwarded it.

What fell out

The response came back:

HTTP/2 302 Found Location: /my-account?id=administrator Set-Cookie: session=jxWIZaT8SD4GsJOR1c724DTq2AjoQpUI; Secure; HttpOnly; SameSite=None X-Frame-Options: SAMEORIGIN Content-Length: 0

That 302 with Location: /my-account?id=administrator was the server saying: "Welcome, administrator — this way to your account." It even handed me a fresh session cookie — the proof-of-login wristband.

No password. The database matched the username, the comment swallowed the password check, and the door opened.

But here's the part that taught me something. In Burp Repeater, when I tried to follow that redirect, it kept bouncing me back to the login page. The attack had worked — so why?

The cookie. The server gave me a new logged-in cookie in the response, but Repeater kept sending the old one. The cookie is what proves you're logged in — not the redirect. So I did the final step in Burp's browser instead: typed administrator'-- in the username, clicked log in, and the browser carried the new cookie automatically.

The page loaded as the administrator. The lab banner turned green: solved.

Why This Works

The root cause is the same as every SQL injection: the app built its query by gluing my input directly into it.

For the password check to mean anything, both halves of that AND must be evaluated. But when my username contains '--, the second half — the password check — gets commented out before the database ever reads it. The lock is still on the door; I just deleted the part of the question that checks the key.

Developers cause this by writing the query as a plain string with the username pasted in. It works perfectly for normal usernames. It falls apart the moment someone types SQL syntax instead of a name.

The fix is parameterized queries (prepared statements). The query structure is locked first, and the username is passed in separately as pure data — never as part of the command. Then administrator'-- is treated as a literal username to search for. No such user exists, login fails, and the comment trick is dead.

Real Bug Bounty Payouts

Authentication bypass via SQLi is one of the highest-value findings, because it hands over accounts directly.

$4,000 — HackerOne. A researcher found SQLi in a login form on a fintech app. admin'-- logged them in as an administrator, exposing the full admin dashboard. Critical severity, paid fast.

$10,000 — private program. A login bypass on an enterprise portal gave access to an internal admin account. Chained with weak session handling, it escalated to full tenant takeover across multiple customer organizations.

$7,500 — Bugcrowd. SQLi in an authentication endpoint let the hunter log in as arbitrary users by injecting their username. Mass account access without a single password.

$25,000+ — multiple programs. When the bypassed account is a super-admin with control over other users' data or billing, these reports cross five figures — one query, total control.

Two characters in a username field. An admin account. That's the asymmetry attackers love.

Where to Hunt This in Real Apps

A practical checklist for login forms:

Try the username field first — it's usually built into the query before the password. Inject administrator'-- (or admin'--) and watch for a successful login or a redirect.

If -- alone fails, add a trailing space (administrator'-- ) — some databases need it for the comment to register.

Probe with a single ' first to confirm the field is injectable (look for a 500 error or a broken response), then move to the bypass.

Watch the response codes, not just the page. A 302 redirect to an account page is success even if your tool then bounces you — that's a cookie issue, not a failed attack.

Remember the session cookie is what logs you in. If you're testing in Repeater, carry the new Set-Cookie value forward, or finish in the browser which does it for you.

Don't stop at administrator. Try injecting other usernames, or ' OR 1=1 LIMIT 1-- to log in as whoever the first user happens to be.