Why is SQL Injection Still Around?

While there are many Web hacking exploits, none are as simple or as potentially destructive as SQL injection. This isn’t news: the attack method has been around for more than a decade. Sadly, for something so old it is still one of the most popular ways to penetrate networks and extract data. And it is easy to find and almost as easy to avoid. Why is SQL injection still with us? It all comes down to a lack of understanding about how SQLi vulnerabilities work.

The problem is that Web developers tend to think that database queries are coming from a trusted source, namely the database server itself. But that isn't always the case, and a hacker or even a casual browser can often take control over the web server. All you need to do is enter a few commands that appear to be valid SQL commands in the right places. The trick is finding the right places.

Actually, trick is too strong a word. You don't need any specialized tools other than a web browser, and you don't need any specialized skills either. It doesn't take much time, and the payoffs could be huge: an intruder could easily obtain a copy of your most sensitive data in about the time it takes to read through this post.

There are two situations where the web and database servers intersect that are relevant here:

1. Places that directly enter database parameters into the URL string itself, or
2. Fill-in forms on web pages that will take this information and pass it along to the database server via the HTTP POST command.

If you think about this for a moment, there are probably dozens, if not hundreds or thousands of places across your various web applications that fit these two scenarios. Can you manually test them all to make sure your developers did everything possible to lock things down? Probably not.

So how does a hacker penetrate your servers with SQL injection? Simple, they use Google and search for the right keywords. There are just a few typical search terms, such as login.asp, asp?id=, php?id=  and other statements indicating database queries that are being passed from the web server to the database. That is pretty depressing: almost anyone can Google this. They don’t have to download any malware or learn any hacking tools. Just by typing in a few lines of code in a matter of seconds they can browse your servers and grab some data.

Ok, so what should you do to protect yourself? Here are a few simple suggestions:

1. First, lockdown your database servers to remove any potential backdoors. Treat your database servers as yet another operating system that requires hardening: delete sample files, eliminate any stored procedures that you aren’t using. Isolate your database servers from the Internet. This isn’t rocket science, people.
2. Do a better QA job and make sure you validate your input scripts and strings that are sent to the database. I know, developers can't test everything. But they should be able to test range limits for all queries and apply input validation checks for all places that accept input from the web. While developers can’t continually test their code, if security is built into the software development lifecycle, automated test can help find instances of SQLi vulnerabilities. Then developers can remediate those risks.
3. Look closely at access rights and user permissions. Change your default admin passwords – now! Make sure all your web and database users have the appropriate access rights. Restrict the access of web-based applications to any stored procedures or other database code.

The key takeaway here: best to validate all inputs that come from the web, keeping in mind what SQL injection can do. And hopefully, I won’t be writing about this in another ten years.