Using SQL Injection Tools in the Field

Friday, June 11, 2010

Brent Huston

E313765e3bec84b2852c1c758f7244b6

As the Internet continues to morph, common attack vectors change.

Info Sec professionals once had the ease of scanning a network and leveraging available vulnerabilities to gain a foothold; but now we’re seeing a paradigm shift toward web applications and the security that protects them.

I’m sure this is nothing new to our readers! We all see the application as an emerging favorite to gain access to the network; just as we’re seeing the web browser gaining popularity in targeting the end user and workstation.

As our Team continues to provide top notch application assessment services, we’re seeing SQL Injection (SQLi) as one major vector of which to take advantage.

Unfortunately, this attack is quite time-consuming, considering the various ways developers code their queries, utilize the architecture involved, and evaluate how the application handles interactions with the database.

In an effort to be more efficient in the quest for vulnerable query strings, we have aggressively tested the plethora of SQLi tools that have been publicly released.

Initially, the Team hoped to evaluate these tools and provide an extensive review on the performance of each. This tech is sad to report that from the three tools tested recently, not one was successful in the endeavor.

After some discussion, the Team concluded there are simply too many variables in play for one tool to serve as “the silver bullet.”

The language and structure of the queries are just a few of the challenges these tools face when sniffing out vulnerable SQL strings.

With so many variables for attackers and penetration testers to overcome, SQL injection testing has become extremely difficult to automate reliably!

That being said, it appears as if these tools are created for use in such specific circumstances that they’re rendered useless for anything but that one, specialized scenario.

So we’re continuing to find this to be a long, drawn out, manual process.

This is not a complaint. Our Team loves the challenge!

It’s just difficult to find a SQLi tool that can adapt to uses other than that for which the tool was specifically created – commonly a source of frustration when trying to expedite the process and finding little success.

Possibly Related Articles:
12102
Vulnerabilities Webappsec->General
SQl Injection Web Application Security
Post Rating I Like this!
384babc3e7faa44cf1ca671b74499c3b
Jonathan Leigh What is the name of the three SQLi tools you tested?
1276292901
384babc3e7faa44cf1ca671b74499c3b
Jonathan Leigh What are the names of the three SQLi tools you tested?*
1276292989
F8f122d50eba11c3af5607575b277bc6
Bryan Miller Scrawlr checks for a very limited set of SQLi issues. I also use the commercial tool known as the Acunetix Web Vulnerability Scanner. The paros proxy tool can also do some checking for this type of issue. SQLMap is another popular choice.
1276310912
1b9a80606d74d3da6db2f1274557e644
Jeff Bird Have you considered ways to stop the introspection of the Web code so the bad guys can’t find the attack vector – in the first place. In a perfect world all Web code would be OWASP Top Ten free when it hits GA and beyond. What can be done if the Web code can’t be fixed because the app is too important or it’s too costly to fix?
Jeff Bird, Mykonos Software, jbird at mykonossoftware dot com
1276373280
1de705dde1cf97450678321cd77853d9
Ian Tibble Yep. For sure, we are still years away from being able to code automated scanners to reliably detect X-site scripting vulns, let alone SQL Injection (a much more complex situation). We are in manual mode for some time to come - and it's genuinely a tough QA testing job.
For a custom developed web app, used by a large company with some degree of functionality (not just a user interface, also an admin interface) - the testing is a really a huge QA job. In nearly all cases, 2 weeks of testing with 4 experienced testers is not enough. Not even close.
At the moment, the budgeting for testing, the testing methodology, and the tools used are all wrong.
What i find frightening is that 99% of custom-made web apps used by big companies have not been tested manually at all.

Checking from a source code perspective is more reliable, and there are tools out there to help with this. This way is more effective, but still - we cannot replace human beings with testing web apps yet. And no, i am not in the business of making money from testing web apps...so i have no reason to make this stuff up.
1276532427
Default-avatar
Rob Lewis Disclaimer: I am associated with a vendor that is launching a new technology in this space. My comments are to advance a paradigm change in approaching the issue of Web application security. As such, I will not identify the company or product.

@Jeff makes THE great point of Web appsec; What can be done if the Web code can’t be fixed because the app is too important or it’s too costly to fix?

Thank you Brent for educating readers on the issues of SQLi tools and Ian for detailing the problems of status quo approaches.

Our approach is not to scan the apps for vulnerabilities but to pre-qualify and inspect all web client queries so that any that are malicious in intent never make it to the Web server/ database, similar to a whitelisting approach but with an AI component. This means Web apps can be protected without costly repairs. In fact, one does not even have to have knowledge of a vulnerabity to protect against attacks that might try and exploit it.

1276616924
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.