SQL Injection Vulnerabilities Are Still Alive and Well

SQL injection has been around for a long time. One would have hoped that with it having been around so long, that we would have eliminated it as a vulnerability in our applications. This is especially true for financial sites on the Internet. Unfortunately, the reality is that we’re still dealing with it and big stories keep coming out. For instance:

PC World: Qatar National Bank claims customer data released by hackers is authentic

Keep in mind that from an architecture perspective, the primary place to stop SQL injection attacks is by validating the input when it comes in. If the input doesn’t match appropriate patterns, especially in the case of a banking application where the likely patterns for each input should be easily defined, you reject it at that level. It then doesn’t get appended or inserted into a text string which becomes¬†the SQL statement to be executed against a database server.

If you don’t get it at this level, the ability to prevent the SQL injection attack gets much harder. Perhaps IDS/IPS can detect based on some text matches. We might be able to do the same thing within the database, say by using DML triggers. However, if the appended text generates queries that are basically what normally gets sent back, none of the back-end solutions are going to be very effective.

Also, keep in mind that there are plenty of tools out there that helps the adversaries. For instance, the Qatar National Bank attack used an open source SQL injection tool to accomplish the hack. So the adversaries don’t have to be exceptionally skilled to pull off an intrusion. Therefore, that means more and more folks are capable of these sorts of attacks. Not a good trend for the good guys.


10 Comments (+add yours?)

  1. Trackback: SQL Injection Is Still Around – Curated SQL
  2. RichardD
    May 17, 2016 @ 11:54:28

    Input validation has its place, but the only real way to stop SQLi is by using parameters. Keep the code and data completely separate, and no input can escape into an executable context.


    • K. Brian Kelley
      May 17, 2016 @ 12:05:13

      Parameters help a lot. But they aren’t foolproof. For instance, if someone is building dynamic SQL in a stored procedure, not doing input validation is going to allow this to pass through. Some platforms will also append parameters to ad hoc queries. An example of that discussion (see last comment):



      • RichardD
        May 18, 2016 @ 06:54:45

        But again, if you’re building dynamic SQL in a stored procedure, using “sp_executesql” and passing the parameters as parameters, rather than concatenating them into the string and using “exec”, will stop SQLi.

        The only time you can’t do that is if you’re using parameters to define dynamic database, table or column names. In that case, you need to validate the names using the system views.

        Parameters might not be “100% guaranteed” in all edge cases on all systems; but they’re still an important part of defending against SQLi.

      • K. Brian Kelley
        May 18, 2016 @ 09:08:19

        They help. But at the end of the day, input validation is the only 100% sure way. And keep in mind that I’m speaking beyond SQL Server.

      • RichardD
        May 18, 2016 @ 09:50:51

        Input validation is not “100% sure”. Apart from anything else, what if your input is a string?

        You can’t reject “Bobby O’Tables” as invalid, because it could be a perfectly valid name. Therefore, you can’t reject “Robert’); DROP TABLE Students;–” either.

        Suggesting that input validation alone will solve SQLi vulnerabilities is *extremely* dangerous advice!

      • K. Brian Kelley
        May 18, 2016 @ 11:11:44

        Richard, you can accept O’Connor if you do proper input validation. Input validation goes beyond just checking to see if something is in the proper domain. It is also formatting as necessary for proper ingestion.

        And keep in mind that input validation solves more than SQLi vulnerabilities. See the recent report on Symantec Endpoint Protection vulnerabilities because they didn’t properly input validate. A security researcher pointed a fuzzer at SEP and bluescreened the box. This is a weakness because proper input validation wasn’t done.


      • RichardD
        May 18, 2016 @ 11:49:00

        Sorry, I can’t get over the fact that a SQL Server MVP specialising in security is giving out such terrible advice!

        Input validation alone will *NOT* prevent SQLi. As I said at the start of this thread, input validation has its place, but properly parameterised queries are the only way to prevent SQLi.

        Even OWASP agrees:
        “Escaping All User Supplied Input … this methodology is frail compared to using parameterized queries and we cannot guarantee it will prevent all SQL Injection in all situations.”

        Telling people that it’s OK to use string concatenation to build a dynamic SQL query, so long as you “validate” your inputs, is a great way to encourage people to write vulnerable code.

      • K. Brian Kelley
        May 18, 2016 @ 11:56:39

        You’re reading into my words what you want to read. I never said that you shouldn’t use parameterized queries. And I didn’t say that you should only rely on input validation. Nor did I ever say that string concatenation of invalidates input is ever okay. However, given that we keep seeing that technique in green field apps, we have to account for it, especially if for some reason we can’t change that interface or layer.

        My point is that if you don’t input validation, you are leaving yourself open. If you think parameterized queries are enough, then I say you are wrong. I’ve given you examples of where parameterized queries aren’t enough. I’ve also given you examples outside of SQLi where lack of input validation leads to serious consequences.

        And, if input validation is done properly and completely, it will prevent SQLi. It will prevent anything other than what you expect. This is a lesson learned from the days of doors and BBSes when we didn’t have techniques like parameterized queries. Should we solely rely on this one technique? Of course not. We talk about security architecture in layers. We call that defense in depth. If you have a failure/issue at one layer, hopefully another layer will stop the attack.

      • RichardD
        May 18, 2016 @ 12:16:20

        Sorry, I was assuming that was your intention, since your post makes no mention of parameterised queries. I agree that they’re both important layers, but I would still argue that parameters are more important.

        The example you gave of SQLi getting past a parameterised query – dynamic SQL built in a stored procedure – would only succeed if the stored procedure is not using a parameterised query. Once your code is “parameters all the way down”, that vulnerability no longer exists.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: