How I Found SQL Injection 💉🔥

(Note: this testing was carried out with the target's permission, and the vulnerability was reported and has since been fixed. Domain and database details have been redacted from the screenshots below.)

Today I decided to write my very first blog, about a recent finding on a target that's an educational platform. I was practicing on TryHackMe and PortSwigger when a notification popped up on my laptop — a new bug bounty PoC video on SQLi. So, as usual, without any delay, I watched the tutorial with pure curiosity about finding bugs.

Like every new researcher does, I went to a bug bounty platform and picked a target to test out what I'd just learned a few hours earlier. But after a few hours, I couldn't find anything. I was disappointed — but then a thought hit me: why not try a different target instead, just to keep practicing?

So I picked another target and started hunting for an endpoint to test my payloads on. I settled on a book-details.php page that took a bookid parameter in the URL — the kind of parameter that almost always talks to a database behind the scenes. Eventually, after throwing a few quotes and payloads at it, I managed to trigger an error on the search box. That error was the first real sign: something back there wasn't sanitizing input properly.

By that point I was exhausted — it was almost 4 a.m. My body needed rest, my eyes needed to close, my mind needed some calm.

Then came the real game-changer: SQLMap.

I grabbed the request straight out of Burp Suite, saved it into a file called target.txt, and ran SQLMap against it with a few flags — — batch — random-agent — level=5 — risk=3 — to automate the detection instead of guessing payloads by hand.

It didn't take long. SQLMap confirmed the bookid parameter was injectable in three different ways:

• Boolean-based blind — the page behaved differently depending on whether a true/false condition was injected

• Time-based blind— I could make the database pause for a few seconds on command, proof the query was actually executing my input

• UNION-based— the real jackpot, since UNION injection lets you pull data directly into the page output instead of inferring it bit by bit

SQLMap confirming the injection point — three different techniques, one unsanitized parameter.

From there SQLMap fingerprinted the stack: LiteSpeed, PHP 7.3.33, backend MySQL ≥ 5.0.12 (MariaDB fork). And then it went further, enumerating the actual database sitting behind the application — over 20 tables, including things like orders, users, enquiries, and course data.

And boom — I could finally see everything behind the site. The database was right there in front of me. I could dump the entire target database, table by table, row by row, if I wanted to.

But we're white hat hackers. Going that far doesn't sit right with us — it's beyond our rules. So I stopped there, documented the finding, and reported it responsibly instead.

Impact, if this had gone unreported: an attacker with this same access could have pulled user credentials, personal details, and order/enquiry data straight out of the database — no login required, just a crafted URL parameter.

Root cause: user input from the bookid parameter was being concatenated directly into a SQL query instead of being passed through a parameterized query / prepared statement.

**Fix:**the platform has since patched this by properly sanitizing and parameterizing the input — confirmed and closed.

Lesson for fellow beginners: finding the bug is the fun part, but knowing where to stop — and disclosing responsibly — is what actually makes you a researcher instead of just someone who ran a tool.