Blind SQL Injection är den mest subtila och tidskrävande formen av SQLi, men är ändå extremt farlig. Till skillnad från Error-based (Rum 4) och Union-based (Rum 5), ger applikationen **ingen direkt information** tillbaka till angriparen – inga felmeddelanden, och ingen stulen data visas på sidan.
Istället utnyttjar Blind SQLi applikationens respons (t.ex. "Produkten finns" / "Produkten finns inte") för att **ställa Ja/Nej-frågor** till databasen, tecken för tecken.
SELECT * FROM users WHERE id = {$id}."Produkten finns" (sant) eller "Produkten finns inte" (falskt).AND för att lägga till ett logiskt villkor. Om villkoret är sant, körs den ursprungliga frågan normalt och ger "Produkten finns". Om villkoret är falskt, misslyckas hela frågan och ger "Produkten finns inte".SUBSTRING() och LENGTH() för att stegvis lista ut ett hemligt värde. Exempel:
?id= 1 AND LENGTH((SELECT password FROM users WHERE username='admin'))=12?id= 1 AND SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1)='s'Genom att upprepa denna process 10-20 gånger per tecken (A-Z, 0-9), kan en angripare systematiskt extrahera hela lösenordet, utan att databasen någonsin explicit skickar det till webbservern. Detta kallas för ett "timing attack" om man använder tidsfördröjningar, eller "Boolean-based" om man använder sant/falskt-responser.
Som alltid: **Använd Förberedda Frågor (Prepared Statements)**. Dessutom bör man undvika att låta applikationens respons (Ja/Nej-meddelanden) vara direkt beroende av databasens logik. Svaren bör vara generiska och inte avslöja information om hur databasfrågan utfördes.