Software is constantly changing and evolving. So why has the Open Web Application Security Project (OWASP) Top 10 List stayed basically the same for the past ten years? Developers are constantly coming up with new ideas and ways to do things. These security concerns are not difficult to solve, and developers know they are happening, so I would posit that the problem lies in hiring sub-par developers.
Security is not something new in the development world. In fact, as I stated above, the same security concerns have existed for years. OWASP publishes its Top 10 list of security risks each year. My goal in this series is to start by giving an overview of security risks, possible prevention measures, and best practices used by Amadeus Consulting. Moving forward I will dive into the top four security concerns in detail, what to watch for, and some preventative tips. There will likely be some overlap, but I recommend you at least glance through each blog. The fact that the risks have remained virtually unchanged for ten years means that not enough developers are practicing preventative measures, so don’t be one of those developers, or one of the people hiring those developers.
It is much more cost effective to build a site with security measures in place, then to go back and fix a site that was poorly built. A common occurrence is the “basement developer” who is not focused on installing proper security measures, a cheaper option than an established development company. With these basement developers, you get a site built quickly and cheaply, and everything is going great, until one of the OWASP Top 10 risks hits and down you go. Then you could face any one of, or a mixture of, the following costs:
- A tarnished brand
- Losing your user’s trust:
- Losing functionality that could include payment processing, a must for an e-commerce company
- Incurring mandatory audits from 3rd party companies
- Possible court costs
- Higher insurance rates
- Senior tech personal losing their jobs
If you’re not a developer, the first step is to have a general understanding of security risks. Then you can ask informed questions when hiring a developer so that you know they are focused on risk prevention.
Here are the 2013 Top 10 Risks:
- Cross-Site Scripting
- Broken Authentication and Session Management
- Insecure Direct Object References
- Cross Site Request Forgery
- Security Misconfiguration
- Insecure Cryptographic Storage
- Failure to Restrict URL Access
- Insufficient Transport Layer Protection
- Invalidated Redirects and Forwards
If you have an existing site, you can hire companies to do a security audit. Not many people think to do this, but I would recommend it if you are even slightly unsure as to the security practices used by your developer.
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, it is more cost effective to build a website with security measure in place than 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.