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. 

About David Strom

David Strom is an experienced tech journalist who has written two computer networking books and thousands of articles on IT products, processes, and people. He can be found @dstrom on Twitter and strominator.com online. He was the founding editor-in-chief of Network Computing magazine and ran editorial operations for numerous blogs, websites and (back in the day) print publications.

Comments (2)

Eric D | April 4, 2016 3:23 pm

How about review code to ensure database queries are properly parameterized, not built by concatenation? While input validation is important too, it's concatenation, where data can be treated as code, that enables this vulnerability.

ss | October 5, 2016 11:00 pm

So here is an idea. Database servers take the incoming SQL query and run it through a parser resulting in a parse tree. Then they turn the tree into a plan and execute the plan.

The essence of injection is that the parser produces a tree different from the one intended by the programmer.

So the fix is to be able to detect unusual parse trees. Walk the tree after parsing and produce a string in canonical form minus the data values. Compute a SHA hash of the string. Keep a table of known hashes for the application/database user. Warn or abort if the server sees an unknown hash.

Obviously, there is a startup problem. So the programmer would have to run the application in a testing mode, extract the hashes after exhaustive testing, and the load the server with the hashes on application startup. Then turn on abort-on-new-hash and no more SQL inject should be possible.

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.