Lab: Blind SQL injection with conditional responses
Intro
This lab contains a blind SQL injection vulnerability. The application uses a tracking cookie for analytics, and performs an SQL query containing the value of the submitted cookie.
The results of the SQL query are not returned, and no error messages are displayed. But the application includes a “Welcome back” message in the page if the query returns any rows.
The database contains a different table called users, with columns called username and password. You need to exploit the blind SQL injection vulnerability to find out the password of the administrator user.
To solve the lab, log in as the administrator user.
Solution
The first lab session is introduce the server’s reaction to sleep command. In this specific example, the postgresql server can be delayed through ||pg_sleep(10)--
Lab: Blind SQL injection with time delays and information retrieval
Intro
This lab contains a blind SQL injection vulnerability. The application uses a tracking cookie for analytics, and performs an SQL query containing the value of the submitted cookie.
The results of the SQL query are not returned, and the application does not respond any differently based on whether the query returns any rows or causes an error. However, since the query is executed synchronously, it is possible to trigger conditional time delays to infer information.
The database contains a different table called users, with columns called username and password. You need to exploit the blind SQL injection vulnerability to find out the password of the administrator user.
To solve the lab, log in as the administrator user.
Solution
There are situations that time-based SQL injection is required. This is when:
- Server does not display db data directly (mostly because output is filtered)
- Server does not display error message.
- No conditional responses can be exploited.
Firstly, I want to test the server’s reaction to time-based sql injection:Cookie: TrackingId=x'%3BSELECT CASE WHEN (username='administrator') THEN pg_sleep(10) ELSE pg_sleep(0) END FROM users--; session=TAlYByR6JTOQBTcT4EqmvXZ9OrHKAtBy
It is worth highlighting that I don’t quite understand why %3B technique is not working in the previous lab session, as the SQL sentence I expected isSELECT * from targetdb where trackingID='x'; pg_sleep(10)
But most likely, the DB sentence is not constructed in a way I thought it is.
Anyway, I continue to verify the length of the password, which is 20 again in this case. Similar to the previous examples, I develop another python script to detect this time delay in response.
1 | import requests |
You may notice that there are two loops of verification in this script. This is because that the uncertainty introduced by the timeout method used in py3 request. Please kindly give your suggestions on this issue in the comment section.
The final password is: 746865504664907dj5tf