SQL Injection Guide

SQL injection happens when user input is concatenated into a database query instead of being passed as a parameter. Detection starts with a single quote and a look for error or behaviour change. From there it goes error based, union based, boolean blind or time blind depending on what the application gives back. The only real fix is parameterised queries.

This is still one of the most common findings in Indian web application assessments, twenty five years after it was first documented.

Why it exists

The application builds a query by gluing strings together. Your input becomes part of the query structure instead of staying data. That is the whole bug.

A parameterised query sends the template and the values down separate paths, so the database knows which is which. That separation is what makes the vulnerability solvable, unlike prompt injection where no such separation exists.

Detection, in order

1. Single quote. Add one to every parameter. An error, a blank page or a changed response means keep going.
2. Boolean pair. Send a condition that is true and one that is false. If the two responses differ, the input reaches the query.
3. Arithmetic. Where the parameter is numeric, try an expression that evaluates to the same number. Same response means the database evaluated it.
4. Time delay. When nothing is visible, a payload that makes the database sleep and an observably slower response is your confirmation.

Confirm manually before reaching for a tool. Testers who run SQLmap first miss the injections that need a custom parameter or an unusual encoding.

The four types

Out of band is a fifth category worth knowing: the database makes a DNS or HTTP request to a host you control. Useful when the application returns absolutely nothing.

Union based, the part people get stuck on

Two things must line up before a union works.

1. Column count. Increase an ORDER BY value until the response breaks. The last working number is the count.
2. Column types. Not every column accepts a string. Find the ones that do by placing a marker value in each position and seeing which renders.

Once you have a rendering string column, you read the database metadata first, then targeted tables. Dumping everything is noisy, slow and usually unnecessary to prove impact.

SQLmap, used properly

Automation is for after confirmation, not instead of it.

• Save the full request from Burp to a file and feed that in, rather than rebuilding the request on the command line
• Target the one parameter you already confirmed, not every parameter
• Start at the default risk and level. Raising them without reason sends thousands of extra requests.
• Stop at proof. Extracting a row count and one masked record demonstrates impact. Dumping a production customer table does not make the finding stronger and may breach your rules of engagement.

WAF and filter bypasses

When a filter blocks the obvious payload, the usual angles are case variation, comment insertion inside keywords, alternative whitespace characters, double encoding, and using a different syntax that reaches the same result. Which one works depends entirely on whether the filter is a blocklist or a real parser.

Worth stating: if a WAF is the only thing preventing exploitation, the application is still vulnerable and the finding still stands.

Reporting it so it gets fixed

An alert box or a database version string is not impact. Impact is what an attacker reaches: record count, data types exposed, whether password hashes came out, whether any of them cracked, and whether the database user could write files or execute commands.

Write it in business terms first. Structure in how to write a VAPT report.

The fix

1. Parameterised queries everywhere. Not string concatenation with escaping. Prepared statements with bound parameters.
2. Least privilege database user. The application account should not be able to read system tables or write files.
3. Allowlist anything that cannot be parameterised. Table and column names in dynamic ORDER BY clauses must come from a fixed list.
4. Do not rely on an ORM blindly. Most ORMs are safe by default and unsafe the moment someone writes raw SQL for one query.

Input sanitisation and blocklists are deliberately not on that list. They are bypassed routinely and give teams false confidence.

Practise this

Find and exploit ten SQL injections by hand before you automate one. The pattern recognition you build doing that is what makes you fast later. Free web challenges on Hacklido.