My First SQL Injection
I've been building up to this one for a while. Out of everything I've worked through in the lab so far, SQL injection is the attack that actually made cybersecurity feel real to me, not because it's flashy, but because of how little effort it took to work.
What SQL injection actually is
Most websites with a login form or a search box are quietly asking a database a question behind the scenes. You type something in, the website turns that into a database query, gets an answer back, and shows it to you.
SQL injection happens when a website trusts what you typed a little too much, and lets your input become part of the actual question it asks the database, instead of just data being searched for. If you're clever about what you type, you can change the question itself.
Breaking in, one character at a time
DVWA has a page that's supposed to look up a single user by ID. I typed this into the box instead of a normal ID:
1' OR '1'='1
That single quote breaks out of the intended query, and OR '1'='1' is always true, no matter what. Instead of returning one user, the page returned every single user in the database. Five accounts, names and all, just handed over because I asked a slightly different question than the form expected.
Finding the shape of the door
Getting from "this is broken" to "I can steal specific data" took a couple more steps. I needed to figure out how many columns the underlying query actually returns, so I tried counting upward:
1' ORDER BY 1-- -
1' ORDER BY 2-- -
1' ORDER BY 3-- -
The third one broke the page. That told me the real query only has two columns to work with. Small detail, but it's the piece that makes the next step possible.
Asking for exactly what I wanted
With the column count confirmed, I could reshape the query to ask for anything I wanted, instead of what the form was designed to return:
1' UNION SELECT user, password FROM users-- -
The page dumped every username in the system, next to what should have been a private password, except it wasn't a password. It was a hash.
A hash isn't a password, until it is
A hash is supposed to be a one-way transformation, you can turn a password into a hash easily, but you're not supposed to be able to reverse a hash back into the original password. In theory, that's exactly the protection that's meant to stop this situation from being catastrophic.
In practice, I noticed two of the accounts had the exact same hash. Same input always produces the same output, so that meant two different people had chosen the exact same password.
I took that shared hash and pasted it into a free online tool called CrackStation, which keeps a massive precomputed list of common passwords and their hashes. It matched instantly.
The password was password.
Why the instant crack matters more than the injection itself
I want to be honest about what actually happened here, because it's more interesting than "I'm skilled." The hash cracked instantly because the password was one of the most commonly used passwords in the world, sitting in a database, protected only by an outdated hashing method with no extra protection layered on top.
If that password had been long, random, and unique, that exact same lookup would have found nothing at all, no matter how much time I gave it. The vulnerability wasn't really in the hashing algorithm, or even really in my SQL injection skills. It was in a person, somewhere, choosing "password" as their password, and a system that didn't do anything extra to protect them from that choice.
Why this one stuck with me
This is the moment where "cybersecurity" stopped being an abstract idea I was studying and became something I'd actually done, on a machine I own, safely and legally. Bad input handling let me rewrite a database question. A weak password meant the answer took seconds to crack open.
Neither half of that story is exotic. That's exactly why it's worth taking seriously.
