protecting against sql injection attacks beyond parameter binding

Question

I have done my homework in reading about protection against sql injection attacks: I know that I need to use parameter binding but:

• I already do this, thank you.
• I know that some of the db drivers my users use implement parameter binding in the most stupid possible way. i.e., they are prone to sql injection attacks. I could try to restrict which db driver they can use but, this strategy is doomed to fail.
• Even if I use a decent db driver, I do not trust myself to not forget to use parameter binding at least once

So, I would like to add an extra layer of protection by adding extra sanitization of http-facing user input. The trick is that I know that this is hard to do in general so I would rather use a well-audited well-designed third-party library that was written by security professionals to escape input strings into less dangerous content but I could not find any obvious candidate. I use python so, I would be interested in python-based solutions but other suggestions are fine if I can bind them to python.

Answer 1

• I already do this, thank you.

Good; with just this, you can be totally sure (yes, totally sure) that user inputs are being interpreted only as values. You should direct your energies toward securing your site against other kinds of vulnerabilities (XSS and CSRF come to mind; make sure you're using SSL properly, et-cetera).

• I know that some of the db drivers my users use implement parameter binding in the most stupid possible way. i.e., they are prone to sql injection attacks. I could try to restrict which db driver they can use but, this strategy is doomed to fail.

Well, there's no such thing as fool proof because fools are so ingenious. If your your audience is determined to undermine all of your hard work for securing their data, you can't really do anything about it. what you can do is determine which drivers you believe are secure, and generate a big scary warning when you detect that your users are using something else.

• Even if I use a decent db driver, I do not trust myself to not forget to use parameter binding at least once

1. So don't do that!

2. During development, log every sql statement sent to your driver. check, on a regular basis, that user data is never in this log (or logged as a separate event, for the parameters).

3. SQL injection is basically string formatting. You can usually follow each database transaction backwards to the original sql; if user data is formatted into that somewhere along the way, you have a problem. When scanning over projects, I find that I'm able to locate these at a rate of about one per minute, with effective use of grep and my editor of choice. unless you have tens of thousands of different sql statements, going over each one shouldn't really be prohibitively difficult.
4. Try to keep your database interactions well isolated from the rest of your application. mixing sql in with the rest of your code makes it hard to mantain, or do the checks I've described above. Ideally, you should go through some sort of database abstraction, (a full ORM or maybe something thinner), so that you can work on just your database related code when that's the task at hand.

Answer 2

I don't know if this is in any way applicable but I am just putting it up there for completeness and experts can downvote me at will... not to mention i have concerns about its performance in some cases.

I was once tasked with protecting an aging web app written in classic asp against sql injection (they were getting hit pretty bad at the time)

I dint have time to go through all code (not may choice) so I added a method to one of our standard include files that looked at everything being submitted by the user (iterated through request params) and checked it for blacklisted html tags (e.g. script tags) and sql injection signs (e.g. ";--" and "';shutdown")..

If it found one it redirected the user told them they submission was suspicious and if they have an issue call or email.. blah blah.

It also recorded the injection attempt in a table (once it have been escaped) and details about the IP address time etc of the attack..

Overall it worked a treat.. at least the attacks stopped.

every web technology i have used has some way of fudging something like this in there and it only took me about a day to dev and test..

hope it helps, I would not call it an industry standard or anything

tl;dr?: Check all request params against a blacklist of strings

Answer 3

So, I would like to add an extra layer of protection by adding extra sanitization of http-facing user input.

This strategy is doomed to fail.

Answer 4

Well in php, I use preg_replace to protect my website from being attacked by sql injection. preg_match can also be used. Try searching an equivalent function of this in python.