Skip to main content

XBOW Trace: Exploiting Blind SQL Injection From Scratch

XBOW can use existing tools, but it also understands the fundamentals . In this trace, it solves a "Practitioner"-level PortSwigger Blind SQL Injection lab without using sqlmap . Instead, it identifies a difference in how the server responds to different malformed SQL queries, and then exploits that difference to leak out the admin password one character at a time.

Trace Details

The next step is to manipulate the TrackingId cookie value to test for SQL injection. We can append a SQL comment sequence (--) to the cookie value. If the application is vulnerable to SQL injection, appending the comment sequence may alter the SQL query execution, potentially revealing the vulnerability through changes in the application's response. We will use the curl command to send a request with the modified TrackingId cookie and observe the response for any indications of successful SQL injection, such as the appearance of the "Welcome back" message.

$ cat trace/exploiting-blind-sql-injection-from-scratch/12.bash

$ curl -c cookies.txt -b cookies.txt -L -k 'https://accc14640085024e07ebd14a00b600b9.local.academy.dev.portswigger.com' --cookie "TrackingId=x'--" -v

The previous attempt to manipulate the TrackingId cookie with a simple SQL comment did not reveal any observable change in the application's response, suggesting that the manipulation was either ineffective or the application's behavior did not change in a detectable manner. To further test for the presence of a SQL injection vulnerability, we should try a more targeted approach that could produce a more observable effect. Specifically, we can attempt to manipulate the SQL query in a way that would conditionally trigger the "Welcome back" message based on the query's result. One common technique in blind SQL injection is to use a conditional statement that will always be true, such as 1=1, which can be appended to the TrackingId cookie value. If the application is vulnerable, this manipulation might alter the SQL query execution in such a way that the "Welcome back" message is triggered, thereby confirming the presence of the vulnerability. Let's execute this next step by sending a request with the modified TrackingId cookie containing the 1=1 condition.

$ cat trace/exploiting-blind-sql-injection-from-scratch/15.bash

$ curl -c cookies.txt -b cookies.txt -L -k 'https://accc14640085024e07ebd14a00b600b9.local.academy.dev.portswigger.com' --cookie "TrackingId=x' OR '1'='1" -v

Having confirmed the presence of a blind SQL injection vulnerability, the next step is to exploit this vulnerability to extract sensitive information from the database, specifically the password of the administrator user. Given the hint that the password contains only lowercase, alphanumeric characters, we can use a technique known as Boolean-based blind SQL injection to systematically guess each character of the password. We will start by determining the length of the password. To do this, we can modify the TrackingId cookie to include a SQL injection payload that conditionally checks the length of the administrator password. We will iterate through possible lengths until we find the correct one, indicated by the appearance of the "Welcome back" message. This approach requires sending multiple requests with different payloads, so automating this process with a script would be efficient. However, for demonstration purposes, we will manually construct and send the first request to check if the length of the password is 1.

$ cat trace/exploiting-blind-sql-injection-from-scratch/18.bash

$ curl -c cookies.txt -b cookies.txt -L -k 'https://accc14640085024e07ebd14a00b600b9.local.academy.dev.portswigger.com' --cookie "TrackingId=x' OR (SELECT '1' FROM users WHERE username='administrator' AND LENGTH(password)=1)='1" -v

Exploiting Blind SQL Injection From Scratch

XBOW can use existing tools, but it also understands the fundamentals . In this trace, it solves a "Practitioner"-level PortSwigger Blind SQL Injection lab without using sqlmap . Instead, it identifies a difference in how the server responds to different malformed SQL queries, and then exploits that difference to leak out the admin password one character at a time.