We covered a scenario of a login form vulnerable to SQL injection vulnerability. The source code allowed us to find a way to display and show the SQL query sent to the database after submitting the form. We discovered that the application encloses the SQL query with double quotes. With this information in hand, we tried injecting the form with manual SQL injection payloads while enclosing them with double quotes which resulted in successful login. This was part of OverTheWire War Games Natas Level 14
Initial Setup and Observation
I accessed the challenge, which presented a login form. I emphasized that this isn’t a brute-force attack but a methodical application penetration test. I examined the provided source code. The PHP code revealed that the username and password are taken from GET requests. Crucially, the code showed a debug parameter. If this parameter is sent with the credentials, the application will print the SQL query being executed. The SQL query structure was SELECT * FROM users WHERE username = "USER_INPUT" AND password = "USER_INPUT". This indicated that the inputs are enclosed in double quotes.
Using a Proxy (Burp Suite)
To systematically interact with the application, I set up Burp Suite as a proxy server. I intercepted a login attempt and added the ?debug parameter to the request. The response confirmed the query structure and showed the inputs enclosed in double quotes.
SQL Injection Attempts
I explained that the goal of SQL injection in login forms is to make the database condition always true. I started testing various SQL injection payloads.
- Failed Attempt (No Double Quotes in Payload): I first tried a payload like
' OR '1'='1. This failed because the application enclosed it in its own double quotes, treating the payload as a literal string rather than executable SQL. - Successful Attempt (Adding Double Quotes to Payload): I then modified the payload to include its own double quotes, for example,
"" OR ""="". This worked because the added double quotes effectively closed the application’s quotes, allowing theOR ""=""part to be interpreted as SQL. This resulted in a “successful login” and revealed the password for Natas level 15. I demonstrated that the key was to ensure the payload itself contained the necessary double quotes to correctly interact with the application’s query structure. I tested another payload,admin" --, which also worked because the double quote closed the username string, and--commented out the rest of the query.
Identifying the Vulnerable Parameter
I tested injecting the payload into the password field while using a generic username like “admin”. This was successful. I then tried injecting into the username field with a generic password like “test”. This did not work. This indicated that the password field was the compulsory field for the injection to work in this specific scenario.
Conclusion
I successfully retrieved the password for Natas level 15 and logged into level 15 using the obtained password.
Technical Commands/Payloads
While there are no traditional “terminal commands” in this video, the following SQL injection payloads were used or discussed:
' OR '1'='1(This was an example of a payload that wouldn’t work directly due to the application’s double quotes)"" OR ""=""(This was a successful payload because it included its own double quotes)admin" --(This was another successful payload)
The video also mentions using the ?debug parameter in the URL to view the SQL query.
Natas Level 15 Level Password:
TTkaI7AWG4iDERzBcEyKV7kRXH1EZRB
