SQL injection is a security exploit in which the attacker adds SQL code to a Web form input box to gain access. Manual testing for SQL injection — as described in this tip on sites that are vulnerable to SQL injection attacks and this paper on advanced SQL injection in SQL Server applications — used to be the only way to determine if your database was vulnerable. Rooting through returned error messages, adding apostrophes and trying to guess database structure information was a long and arduous process. Plus, it didn’t guarantee that you’d find all SQL injection vulnerabilities, much less be able to view or extract data.
Now, several automated SQL injection tools are available to carry out SQL injection assaults. Offering features from front-end Web application and database footprinting to the extraction of database tables, free and commercial hacking tools are available to carry out such attacks.
If you have a Web front end connected to a backend database that allows dynamic user input supported by ASP, ASP.NET, CGI and similar scripting languages, odds are you’re susceptible to SQL injection. In typical ethical hacking fashion, what you can do (and should do on a periodic and consistent basis such as once per quarter or after any major system changes) is perform automated SQL injection attacks against your own systems to identify just what can be compromised from the outside world. No more “select” this or “apostrophe” that — let your tools do the work for you.
It’s a two-step process to test your own systems for SQL injection vulnerabilities in an automated fashion. I’ll outline the process here.
Step 1: Scan for vulnerabilities
First, you must scan your site with a Web application vulnerability scanner to see if any input filtering or other SQL injection-specific holes exist. Since I’m always in a time crunch and need good reporting capabilities, I like using commercial tools such as N-Stealth Security Scanner, Acunetix Ltd.’s Web Vulnerability Scanner and (my favorite) SPI Dynamics WebInspect. Free tools like Wikto can often find these vulnerabilities as well.
Step 2: Begin SQL injection
Once you determine whether or not your target system is vulnerable to SQL injection, your next step is to carry out the SQL injection process and determine just what can be gleaned from the database. Note that I don’t recommend injecting actual data or attempting to drop database tables — both can be bad for you and your database’s health. Finding potential SQL injection holes is one thing but actually carrying out the attacks in an automated fashion is quite another.
My favorite tool for automating the actual SQL injection process is SPI Dynamics’ SQL Injector (which comes as part of the WebInspect). You can also use Absinthe, shown in Figure 2.
Both tools allow you to perform basic and blind SQL injection. As a side note, both types of tests should be performed — especially if basic SQL injection doesn’t return any results. These tools can query and extract data very quickly in an automated fashion, easily dumping large tables in just a matter of minutes.
Other options include a free Web services testing framework from Foundstone Inc. called WSDigger that can generate a basic SQL injection attack. Or there’s Automagic SQL Injector, which you can use to perform a few automated SQL injection queries. You can also use Sleuth with its SQL injection plug-in, but it requires SA access, which essentially negates the benefits of anonymous external testing.
Finally, if you want to get some hands-on practice outside of your live systems and learn more about SQL injection and other front-end Web application vulnerabilities that can lead to database compromise, check out Foundstone’s Hacme Bank. And WebGoat is another one.
It doesn’t matter which tools you use for automating your SQL injection tests as long as you’re comfortable with how they work and you’re getting the expected results. Just do something — the bad guys certainly are.