Posted by Zack Allen on November 19, 2015
In 2016, OWASP will publish the fifth iteration of the OWASP Top 10. First released in 2004, the OWASP Top 10 is a popular enumeration of the 10 most important web application security vulnerabilities as determined by severity as well as real world prevalence. As we await publication of this latest version, we can’t help but ask ourselves, “if the world’s most popular list of web application security vulnerabilities clearly shows what we should worry about and focus our efforts towards, why do the same issues continue to appear year after year?”
On July 1, 1940, the Tacoma Narrows Bridge first opened, connecting Tacoma to Kitsap County. It was the third longest suspension bridge in the world at the time (behind only the Golden Gate Bridge and George Washington Bridge). But, on November 7, barely four months after it opened, it collapsed into the Puget Sound. The reason for the collapse was mechanical resonance; the wind in the Puget Sound on that day just happened to provide an external periodic frequency that matched the bridge’s natural structural frequency.
So, what does a bridge have to do with application security? Well, if you’re a college freshman studying physics or mechanical engineering, the example of the Tacoma Narrows Bridge will likely be pretty close to page one in your text book as an example of what not to do.
On December 25, 1998, Phrack Magazine published one of the first articles describing SQL injection. The article described how an application that includes user input in a concatenated SQL query string could open itself up to arbitrary SQL execution on the database. This was almost 17 years ago, and yet you probably won’t find any mention of SQLi in any computer science textbook. Not only are there probably thousands of vulnerable applications still in production nearly two decades later, but there are new applications being developed today that contain SQLi and other injection vulnerabilities.
When developing software, four variables exist: time to develop, cost to develop, functionality and features, and defects (including security defects). Management can only set three of these variables; the fourth variable is dependent on the development team. All too often, management mandates a given feature set by a given date at a given cost and ignores potential defects that will make their way into the software.
Developers, who are already under the pressure of tight delivery timelines, are forced to compromise the security of their software in favor of functionality. Moreover, as developers focus on how to get their software to work, attackers focus on how to get software to break. Attackers abuse software by finding ways to make it do things its functionality-focused creators never intended it to do.
In order to develop secure software, not only must security be a priority throughout the development life cycle, but a security mindset is also required from inception through maintenance.
In the past, security professionals have warned against M&M security—security that is hard and crunchy on the outside but soft and gooey on the inside. Back when network security was the primary concern, enterprises focused most of their effort on protecting the perimeter. Firewalls, intrusion detection systems, and proxies became necessary tools to keep the bad guys out. However, in order for software to be useful, there has to be an entry point for our users (i.e. the front-end web applications running on port 80 or 443).
In order to extend the concept of perimeter security to the application layer, many firms rely on web application firewalls or WAFs to protect their sensitive, internal assets. However, if an application has security vulnerabilities, placing a WAF in front of it will not solve the problem. An attacker can use a simple tool like Nmap to detect or fingerprint the WAF being used by a target application. At that point, the attacker simply has to Google ‘XXX WAF bypass’ to find ways to get his payloads to the target.
And don’t forget about internal web applications that are not exposed to the Internet. They are just as likely to have a SQL injection or cross-site scripting vulnerabilities as applications that are accessible to external users. Many firms ignore the threat of malicious insiders or forget that at some point their network will be breached by attackers who will then have access to those internal applications.
Security professionals such as myself would like nothing more than for the current OWASP Top 10 to become a thing of the past. In order for this to happen, enterprises must fundamentally shift how they think about security. Security cannot be that dependent variable; it can’t be what we focus on with all of the “extra” time left over at the end of a project. Security must be a primary focus from inception through maintenance. Security touchpoints must be integrated into every phase of the software development life cycle—not just the testing phase, but the coding, design, and even the requirements phase. Instead of focusing on defending the perimeter and hoping for a clean penetration test report, development teams should actually fix the security defects in their code. Developers should learn from the mistakes of the past and actively work to resolve the most common security vulnerabilities —until they aren’t common at all anymore.
There are many factors that have caused most of the original OWASP Top 10 to linger around in our web applications for over a decade.
At Synopsys, we work with our clients to help them mitigate these factors and build security in to their software from the very beginning. Our goal is to shift the way firms secure their applications so that by the time the OWASP Top 10 for 2019 is released, it will look completely different.