SQL Injection

SQL injection (SQLi) happens when an app builds a query by concatenating untrusted input into SQL, so part of the input runs as code instead of data. It can bypass a login, dump an entire database, tamper with records, or — on misconfigured servers like MSSQL — reach OS command execution, a close cousin of command injection and, on a domain-joined box, a pivot straight into Active Directory. It’s decades old and still one of the most damaging web bugs, because a single unsafe query is enough.

Common Techniques

• In-band (UNION / error-based) — results come straight back in the response or in error messages.
• Blind (boolean / time-based) — no data shown, so infer it bit by bit from page differences or SLEEP() delays.
• Out-of-band — force the database to make a DNS/HTTP callback to exfiltrate data.
• Authentication bypass — ' OR '1'='1' -- makes a login WHERE clause always true.
• Second-order — input stored safely, then used unsafely in a later query.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Testing

-- Manual probe: a quote that breaks the query hints at injection
'
' AND 1=1 -- -    -- these two should render differently
' AND 1=2 -- -

# Automate detection and exploitation with sqlmap
sqlmap -u "https://target/item?id=1" --batch --dbs
sqlmap -u "https://target/item?id=1" --batch -D appdb -T users --dump

Log every injectable parameter, the technique that worked, and any data you extract, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

Remediation

Use parameterized queries / prepared statements (or a solid ORM) everywhere — that’s the fix that actually closes SQLi, since data can’t be reinterpreted as code. Apply least privilege to the app’s database account, disable dangerous features like xp_cmdshell, and return generic errors. A WAF adds defense in depth but doesn’t replace parameterized queries.