Once again a major web site has been hacked using good old-fashioned SQL injection. Over the weekend Nokia’s developer forum was hacked, resulting in a Homer Simpson face being put up on their web (funny) and the loss of names, email, and other personal for many developers (not funny). This is but the latest in a now very long string of SQL injection attacks, and personally I don’t see much excuse on the part of those attacked.
It might have been possible a year ago for a major corporation to decide that the threat of SQL injection was less than the cost of preventing it, although that’s debatable. In an AntiSec world, that is no longer possible. The threat is well known, as well as the mechanisms to prevent such a threat. There are well-known steps once can take to avoid injection issues. This will not guarantee that hackers cannot do anything, but why make it easy for them. One LulzSec programmer said in an interview that it was almost embarrassing to use such a simple hack – it made him look bad as a hacker.
So what CAN be done to improve software security? Well a few simple things: policy, tools & training.
Policy
It all starts with having a proper security policy. This means the organization needs to think ahead of time about what can happen and how to prevent it. Assessment of the likelihood of particular threats happening, their ease, the cost of dealing with them versus that cost of preventing them, all need to be part of a standard threat assessment. If you’re not sure how to do this, seek professional help from someone that knows what they’re doing.
Having the correct policy based on real world information lets you control and justify costs and scheduling delays. Frequently organizations end up checking security in the QA phase of software development where it is way too late to do what’s needed. Better to bake it into the process.
Be especially careful not to fall in the trap of “We’ll make sure nothing bad ever happens” which can lead to further problems. You need to understand that at some point someone WILL get in, and decide now how you’re going to mitigate the loss. In other words, you shouldn’t have passwords stored in plain text on the fallacious theory that you can prevent all break-ins.
Your security policy should include at a minimum requirements for password strength, encrypting private data, proper use of admin passwords, and other such items.
Tools
First and foremost – there are NO silver bullets. There is not a single tool or a set of tools out there that will secure your site. Such a solution is not likely in the foreseeable future either. That being said, there are definitely tools available to make the process of securing your site and software easier. Such tools should be a critical part of your security tool kit.
Static analysis is the most critical tool to prevent SQL injections. Outside of making all your database calls into stored procedures, it’s about the only thing that can really batten down the hatches. If you really want to secure your site, you must have static analysis tools that will identify dangerous input API’s, and check that validation is always, always, always performed.
Which leads me to my next point, there are those who concentrate on penetration testing tools and fixing issues found there. They believe that flow analysis is a much more interesting technology that stodgy old static analysis. Therein lies the problem. Flow analysis is a fine paranoia tool to make sure that you didn’t miss anything, but it can never find all paths through a site or application, and cannot ensure that you are safe merely because it didn’t find anything.
Use static analysis to make sure you’re validating everything, use penetration testing to be sure that your static analysis is setup properly. If pen testing finds anything, fix it, but look back at your process, tools, and procedures and figure out how it slipped through the cracks. Pen testing tells you more about your security infrastructure than it does about your software.
Training
I’m including various techniques that reduce or eliminate the possibility of SQL injection as part of training. Learning techniques is after all the point of training. I have worked with organizations who were trying to improve security and not surprisingly find developers challenging the results of a security assessment. It’s not a measure of how smart or experienced they are, but rather another reminder that on the whole the software industry is lacking proper training in secure software development.
Michael Sutton, VP of security research at Zscaler said it very well: “It’s very easy to create a Web application today. It’s not easy to properly secure that application.”
The techniques to be used should easily map back to your security policies. For example encryption should be required for all private data. Database credentials must be appropriate to the account, IE the web site should not be accessing the database as an administrative user.
Used stored procedures where ever possible. They will take some extra effort, but make it much more difficult for hackers. As a side benefit you may see a performance improvement switching to stored procedures. You also make it less likely that a missed input validation will have a negative effect.
Validate all input, every bit, no matter where it comes from. Don’t just check input fields in forms, also check when you’re pulling data out of the database, from an input stream, etc. No excuses, steps. Hackers frequently gain access to systems in an incremental fashion – image that someone was able to subvert your very secure web forms because he found a way to put corrupt data in a field in your database.
When validating do not rely on penetration testing and flow analysis to find out if you’ve used tainted data. As mentioned above, these techniques are not thorough. Use proper naming conventions so you can spot input methods, black-list unknown API’s during testing, and require that the distance in the code between input and validation is zero. This means that your flow analysis won’t find anything, but that’s OK. It also means that you’re safe.
There are many other simple things you can do. To find out more in detail, check many of the excellent articles and tutorials on the web, such as Strike Back at SQL Injections and Stop SQL Injection Attacks Before They Stop You, seek expert advice, and feel free to ask questions.
Conclusions
SQL Injection can almost always be avoided. Yes, there are other security issues out there that you need to handle as well, but this is one that can be easily executed and is very likely to happen. It’s also relatively easy to prevent, which should put it high on anyone’s to-do list if they’ve made a thorough risk assessment.
Resources
Thank you for a great post.
Pingback: SQL Injection is So "2000-and-Late" - The Code Curmudgeon
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 injection should be possible.