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:
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.