Burp suite sql injection5/20/2023 ![]() Turbo Intruder takes the values that you specify from the file path, that you specify (see below image). We need to specify the input that would be used, in place of this placeholder. The %s is just a placeholder, to instruct Turbo Intruder, to replace with the input that we specify. SUBSTR((SELECT password from users WHERE username=’administrator’),%s,1)=’%s’ SUBSTR((SELECT password from users WHERE username=’administrator’),1,1)<’a’ We can also use the in-built Burp Intruder, however, as this is a Community Edition, we don’t have the functionality to configure the number of concurrent requests, that we can send. Similarly, we can manually “brute-force” each character, or we can use another tool, called “Turbo Intruder”, that does this in an automated fashion. If we try to check, if the condition is lesser than 0, the application would throw an error. Since the response gave a 200 OK, we now know, that the first character is greater than ‘a’. If this character is greater than ‘a’, the condition would result in TRUE. This query checks for the first character of the administrator’s password. Let’s alter the condition, to check for the first character of the administrator’s password, in the SQL database. It looks like the application didn’t handle the error properly, which we can leverage. ![]() We see that the condition 1=2 triggers an error. ![]() The above query resulted in a 200 OK response. Using this technique, we can check whether the application behaves differently or not. The above condition is 1=1, which is true. Since 1/0 would result in a divide by zero exception, we should see that error on the UI side. The line test’ OR SELECT CASE… checks for a condition, and based on that condition, the output would result in either ‘1’ or 1/0. However, if you look at the response, there is no indication that we successfully logged in, or whether the above SQL query returned any records. Since 1=1 always evaluates to true, the condition succeeds at the back-end database side, and the attacker logs in.Īfter sending this request, we get a 200 OK response. The line test’ OR 1=1– tries to bypass existing cookie restrictions, and login to the application. Let’s modify the request, and send it to the web application. As we already know the vulnerability exists in this parameter, let’s go ahead and add some malicious input. Ideally, we would check if the vulnerability actually exists using other techniques, that are beyond the scope of this article. An attacker, can replace this TrackingID, with parts of an SQL query, which would cause the application to behave in a manner that was never intended. This ID is used directly in an SQL query. Repeater is a functionality in Burp Suite, that enables us to view the requests and responses in real-time, without having to reload the page every time.Īs mentioned in the lab description, the vulnerability exists in the “ TrackingId” parameter of this request. I have already intercepted the request, using Burp Suite. I had already solved this lab, but will be doing the same again, for the purpose of this article.Īccess the lab, and intercept a request from the web browser. The goal of this lab, is to exploit this vulnerability, to grab the administrator password, and login to the application. If this condition is FALSE, the web application throws an error. If this condition is TRUE, the response is loaded correctly. We typically try to get a different response from the web application, based on a particular condition. This is where we use a blind SQL injection. However, if the web application’s response doesn’t show any difference, regardless of the request, then it becomes difficult for an attacker to know if this vulnerability exists. In order for an attacker to know if this vulnerability exists, the web application should ideally behave differently based on the request he/she sends. This enables the attacker, to send malicious SQL query strings, that will be processed by the underlying database, in a way that was never intended. SQL injections take advantage of applications, that don’t process user input correctly. ![]() The techniques mentioned should NOT be used for illegal purposes, and should NOT be used on machines without prior authorization from the machine owner. In this article, I will be exploiting a Blind SQL Injection vulnerability, on a vulnerable web application, that is hosted at Port Swigger Web Academy.ĭisclaimer: As with all things related to ethical hacking, this machine is an intentionally vulnerable machine, whose purpose is to learn ethical hacking techniques.
0 Comments
Leave a Reply. |