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, "SQL injection: Secure your Web applications" and this paper -- 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 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.
An example of two different SQL injection vulnerabilities discovered by WebInspect is shown in Figure 1.
Figure 1. Common SQL injection vulnerabilities found using WebInspect.
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.
Figure 2. Absinthe tool is used to automate SQL injection analysis.
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.
About the author: Kevin Beaver is an independent information security consultant, author and speaker with Atlanta-based Principle Logic LLC. He has more than 17 years of experience in IT and specializes in performing information security assessments. Beaver has written five books, including Hacking For Dummies (John Wiley & Sons, Inc.), the brand new Hacking Wireless Networks For Dummies and The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach Publications). He can be reached at firstname.lastname@example.org.
This article originally appeared on SearchSQLServer.com.