It should be a wake-up call to the industry that the most common security threats have remained nearly unchanged since the Open Web Application Security Project first released its list in 2003. The number one threat on the most recent incarnations of the Top 10, injection, has been on part of the list since its inception in 2003.
Injection — or injection flaws — occurs when hostile, untrusted data is sent to an interpreter or user as part of a command or query, which allows attackers to access often critical and private data without authorization. Injection is a simple hack that — noting the length of time on the list — bad actors have been using for a long time.
Hackers can easily automate injection attacks using their established botnets as soon as a vulnerable application is launched in the cloud. When a hackable system is launched on Amazon Web Services or any other cloud system, within seconds, an injection attack could issue a direct database command to delete data or access vital information such as social security numbers or passwords.
What’s frustrating about injection attacks is not just how easy they are to execute, it’s that they’re actually quite simple to defend against. There are only a few small techniques that need to be made by an application’s developers to make a web application completely impervious to an injection attack, and yet they persist as a major vulnerability to a large number of web applications.
There are a number of reasons that what should be a simple vulnerability to prevent has remained so prevalent for so long.
Part of the problem is the economics of “moving fast and breaking things,” which favors fast iteration of web products over a more holistic approach. Security executives could easily create risk profiles and build in solutions as applications are updated.
However, it isn’t as easy to quantify the amount of damage a company could incur through a breach — losing customer data, lawsuits, restitution, sales funnel danger due to loss of customers’ trust, not to mention the PR disaster — as it is to quickly experiment with insecure versions of products and then launch them before examining their vulnerabilities.
Across web application development organizations, there is no default security framework to prevent even the simplest of attacks, such as injection.
Some of the Solutions to Implement Now
There are a lot of web application companies that are likely to be high on the list of obvious hacker targets, but there are also plenty of solutions that can be implemented quickly to bring the necessary amounts of protection to the engineering process and remove them from being targeted.
Short-term capital investment in a one-time security scan for vulnerability analysis is an easy way to access whether or not you are vulnerable, as is engaging a red team, but there is also a long-term, cultural solution that could benefit technology companies for decades to come and would likely shake threats such as injection from the Top 10 security threat list. It starts with how security is approached as part of computer education.
Teaching with Security in Mind
One of the real reasons that injection has remained part of the list of web application threats for so long is that there is no emphasis on indoctrinating engineering students to prevent even one of the simplest things hackers do. It’s just an accepted fact that someone can walk out of college with a computing degree without an inkling of understanding of how to build a secure application or invulnerable code.
It would be pretty easy to enact ways to change this across higher education, and both the universities and technology companies need to partner to make this happen.
Higher education needs to make security a core part of a computer science syllabus. Also, companies need to be proactive to make sure they are partnering with universities and hiring from colleges that produce highly-skilled developers.
I left college writing the worst, most insecure code possible. I simply didn’t know any better. However, if I had spent four years having all of my assignments vetted and automatically scanned for vulnerabilities or maybe penetration tested, I would have developed an innate habit of building code with security in mind. If I knew that I could fail a course because of a security failure in my code, I would have upped my security game long before I started working in my first developer role.
One way to enact this change is for companies to only take interns from schools that actually teach security. Imagine the time and money that could be saved if those coding an organization's applications or updates had an understanding of what the OWASP Top 10 threats were?
Additionally, it would be such a differentiator if a higher education institution could emphasize to potential partners and hiring organizations that its engineering students build code that is vetted and scanned for security risks. Developers who code with an eye on security would help prevent the crisis of these persistent threats and eliminate the costs of training after breaches occur.
The schools that start producing graduates with a knowledge of the most consistent security problems should be at an advantage in a highly competitive market for the best students and the perception of feeding future employees to the most sought-after companies.
For organizations building web applications, hiring engineers with security knowledge and implementing vulnerability checks into development processes should be a no-brainer for a number of reasons. This change needs to happen sooner than later.