The Open Web Application Security Project (OWASP) was founded in 2001. This non-profit organization seeks to educate and inform developers on secure development practices, and provides developers with tools to create web applications securely. One of their flagship projects is the Top 10 list of web application security flaws. The goal of the Top 10 list is to raise awareness about problems that exist with vulnerabilities in web applications and to educate developers about how to find and avoid the vulnerabilities.
The OWASP Top 10 list is extremely well known; it is impossible to walk through the show floor at a security conference without encountering at least some mention of the top 10 list. The Top 10 list is cited several times by the PCI Security Standards Council Penetration Testing Guidance and has been used as an acceptance test criteria for contract fulfillment for public procurement.
OWASP released the first version of the OWASP Top 10 list of common security vulnerabilities in January of 2003. The top 4 vulnerabilities in 2003 were
1. Unvalidated Parameters
2. Broken Access Control
3. Broken Account and Session Management
4. Cross Site Scripting
OWASP periodically updates the list and released the most recent version in June 2013. The list now focuses on risk and lists the top 4 web application security risks as
1. Injection
2. Broken Account and Session Management
3. Cross Site Scripting
4. Insecure Direct Object References
Injection was #6 on the 2003 list and “Unvalidated Parameters” was deemed to be in the same larger group (“Unvalidated Input”) as injection flaws and cross site scripting so it is no longer called out separately. The top 4 were picked for brevity for this article, but I encourage you to compare the full lists for greater impact. With this in mind, the similarities between the two lists released 13 years apart are startling and humbling.
Have we, as security practitioners, made no progress since 2003? The 2013 report does offer some hope: Cross Site Request Forgery (CSRF) fell from #5 to #8. The authors of the report state, “We believe this is because CSRF has been in the OWASP Top 10 for 6 years, and organizations and framework developers have focused on it enough to significantly reduce the number of CSRF vulnerabilities in real world applications.” This is great news, but the question remains, “Why has the list has been largely static for more than a decade?”
The Top 10 list comes with a great deal of information about how to detect whether your web application is vulnerable, how to prevent the vulnerability, example attack scenarios, and links to reference materials. If that is not enough, then there are numerous free training opportunities, videos, tutorials, developer guides, cheat sheets, and white papers online. There have even been multiple books written about the subject (in more than one language). OWASP has systematically attacked the problem of web application security by providing an example web application that is vulnerable to the risks (WebGoat), by providing security control APIs (ESAPI) and libraries (AntiSamy) to help with secure development, rulesets (ModSecurity Core Rule Set), and by providing a tool that tests applications for the vulnerability classes (OWASP ZAP). There’s much more, but you get the picture.
And yet, the problems persist. It’s enough to make a security person want to give up and go home. Instead, I turn on the local weather report and take comfort in knowing that there is another group of people who can repeatedly get things wrong and still keep people coming back.
If education, training, tools, frameworks, and bug bounties won’t rid us of web applications that fall to these risks, then what are we to do? (This is a question that gets bantered about frequently at security conferences.) It is certainly worth an honors thesis in sociology to study this question rigorously, but failing that, I will unoriginally suggest that part of the fault lies with the way that developers learn to program and use reference materials after they have learned.
All of this information gets labelled “security” and is not core to learning how to code. Intro classes abstract away complexity including security concerns to get the the heart of the concept that they are trying to teach. Example code also regularly omits checks, which complicate the example without elucidating the core concept. API documentation often covers the functionality of the API, but omits information how how the API can be misused and how it should be properly used. An example will illustrate what I mean:
From the OWASP Top 10:
[A1: Injection] The application uses untrusted data in the construction of the following vulnerable SQL call: String query = “SELECT * FROM accounts WHERE custID=’” + request.getParameter(“id”) + “‘”;
… the attacker modifies the ‘id’ parameter value in her browser to send: ‘ or ‘1’=’1. … This changes the meaning of both queries to return all the records from the accounts table.
In fact, two of the top 10 problems in the OWASP list are caused by creating problematic select statements for use in querying data from the backing database for the web application. Let’s take a look at what the MySQL developer documentation says about security issues in the documentation for the SELECT statement:
“ “
That is not a typo. You are reading that correctly.
These issues are not addressed at all by the developer documentation for the SELECT statement. The only mention of security in the API documentation web page for SELECT is in the user comments. I can hear you protesting already, “That’s not fair. Web applications are just one usage model for the database; web developers should be looking at language-specific information for creating their SELECT statement; and it would be unclean to muddy up the documentation with security information that applies to just one database workload.”
You are absolutely right. I cannot argue that point. It is unpalatable, but after more than a decade of facing these issues (over and over and over again), isn’t it worth a little messiness to try another approach to solving the problem?
In fact, none of the top five search returns for the query “mysql select” mentions anything about any security implications, although two of the pages are about creating select statements for use with PHP. (I gave up looking after scanning the first three pages of search results to no avail. Your millage may vary since search results change over time and are often customized.)
A recent study found that cybersecurity education at the college level is weak. Top universities don’t require it and, in some cases, don’t provide cybersecurity coursework. However, even if universities did provide rigorous cybersecurity training (and it is absolutely essential that they do so), the impact on web application developers would not be profound. The 2016 Stack Overflow developer survey shows that the majority of developers are self-taught. Only 43 percent of developers have a BA or a BS in computer science or a related field.
My take on all of this is simple — writing yet another “security” paper isn’t going to do the trick. Security practitioners need to do a better job of getting our messages integrated into core developer documentation.
