Most of the SQL injection flaws I am uncovering end up being false positives or potential input validation weaknesses that aren't exploitable. Whether this is due to improved coding and QA or simply the newer languages such as C# helping developers help themselves remains to be seen. The reality is that SQL injection does exist and it's something you still need to be checking for in your Web applications. One oversight is all it takes to make the headlines.
Here's what you can do to seek out SQL injection flaws and eventually eliminate them from your applications:
- Understand the essence of SQL injection so you can appreciate the importance of using good tools to find it – not to mention what everyone involved in the SDLC is up against when it comes to plugging the holes.
- Find the right tools. As with cross-site scripting (XSS) you want to automate the SQL injection discover process if possible. Otherwise there are just too many entry points (URLs and form fields) and too many combinations of input to do it manually. A good Web vulnerability scanner such as HP's WebInspect, Acunetix Web Vulnerability Scanner, and N-Stalker Web Application Security Scanner is an absolute must-have for uncovering SQL injection flaws. If possible use a tool that does both SQL injection and blind SQL injection. They are different and you'll often find one and not the other.
- Scan your systems as an untrusted outsider as well as a trusted user. Your main exposure to SQL injection is untrusted outsiders gaining access. However, where possible you really should perform authenticated SQL injection scans while logged in at every user role level. Just because a generic user can't find/exploit SQL injection doesn't mean that someone with different privileges can't do so.
- Validate any and every SQL injection finding – even if they're "potential SQL injection" or SQL injection in a seemingly non-critical part of your application. Using the built-in SQL injection tools (found in most Web vulnerability scanners) I have seen exploitable SQL injection on findings that the scanners weren't able to confirm. Double check their work.
- Test every site/application regardless of its importance. Your e-commerce or online banking system may be the most critical but other Web systems can still expose your environment via remote system command execution (i.e. xp_cmdshell in SQL Server) which could lead to subsequent exposure of more critical systems.
- A down and dirty manual check for SQL injection is to simply enter a single quotation mark (') into form fields or in place of URL variables. If a SQL error is returned, then you might very well have a SQL injection vulnerability. You can then pursue SQL injection further on that specific page with a tool manually (ouch!) or using a tool such as Absinthe which can really simplify the process.
Unlike most cases of XSS, SQL injection does put sensitive information at risk. It's something you can't afford to overlook. If you haven't already discovered SQL injection, the first time you do will be exciting. Short of exploiting a missing patch and gaining remote access using Metasploit, siphoning database tables through your Web front-end is the ultimate ethical hacking experience.
About the author: Kevin Beaver is an independent information security consultant, speaker and expert witness with Atlanta-based Principle Logic, LLC. He has over 20 years experience in the industry and specializes in performing independent information security assessments revolving around compliance and information risk management. Kevin has authored/co-authored seven books on information security including the ethical hacking books, Hacking for Dummies and Hacking Wireless Networks for Dummies (Wiley). He's also the creator of the Security On Wheels IT security audio books.
This was first published in November 2009