Over 160 million credit card numbers compromised, $300 million stolen, and immeasurable suffering for the identity theft victims. The 2014 super hack should have never happened. The thieves utilized SQL Injection, a security threat that has been listed on OWASP’s Top Ten list for years. So why aren’t developers taking the proper preventative steps?
As I said in my last blog kicking off this security series, it is more cost effective to build a website with security measure in place then to go back and fix a site. Also, it is much more cost efficient to build a secure site then to have it hacked by thieves who end up stealing millions of dollars.
When it comes to theft, we often don’t watch out for those closest to us. If you park your car in your driveway, you don’t think your family member or roommate is going to steal it. If you leave it unlocked on the street, you know you run the risk of someone stealing it. In the case of injection as a security concern, your trusted admin users are your biggest threat.
So how does this happen? Any general user can introduce code into your system without your knowledge or approval. The user merely logs on to any normal login page. Once they have access to your system, they find a hole. Trust me, if there is a hole anywhere in your system, they will find it and use it to inject their code into your system. This code can remain in the system for very short time periods or could potentially remain for the rest of the life of the system. And guess what? Just one injection point can lead to system wide breaches. This code can collect any and all data, including credit card numbers, social security numbers, and confidential information.
More important than understanding the basics of injection, you should know how to prevent it from happening. Prevention is not overly difficult. First and foremost, if you are working with a developer, make sure they have some experience under their belt. The typical excuse you may hear from a “basement developer” is that they did not realize that a certain point was an injection point. Developers with experience know what to look for, and also realize that if there is a hole, someone will get in. Extensive documentation for developers on preventing injection exists, and these best practices should always be used. The overarching solution needs to include users being treated all the way through the system as users. If you are never escalating users to trusted users, you may eliminate the injection concern.
Watch for my next blog, as I scare you with cross-site scripting attacks, the number two on the OWASP Top Ten.