According to Verizon’s 2014 Data Breach Investigations Report,1 “Web applications remain the proverbial punching bag of the Internet.”2 Things haven’t improved much since then.
What is it about web applications that makes them so precarious? There are three primary answers. First, since most web applications are configured or coded specifically for the organizations they serve, they are more unique than commercial off-the-shelf software, which is often rigorously tested to a wide marketplace. Because of this uniqueness, developers must pay extra attention to each application in order to find and eliminate security problems.
Second, most web applications are available to the entire Internet, which means anyone, at any time, can poke and pry to try to break them. There are nearly 4 billion people on the Internet, and most of them primarily use the web.3 That doesn't count enormous numbers of bots trawling the web every day; some say there are more bots than humans viewing sites.4 If you have a website, someone—or something—is looking at it.
Third, the World Wide Web itself was never designed with robust security features. HTTP, the protocol underlying all web traffic, is stateless, meaning each request for data between client and server is independent of all previous requests. Add-on protocols and tools such as web cookies and session management trackers are needed to maintain consistency from when users first authenticate until they retrieve data.5 As with all add-on tools, these are less than ideal solutions and can introduce gaps in coverage and capability.
Enter the OWASP Top 10, the most famous project of the Open Web Application Security Project (OWASP). A release candidate of the 2017 OWASP Top 106 is out and due to be finalized in November. This new version updates the 2013 list by combining two old items, “Insecure Direct Object References” and “Missing Function Level Access Control,” into a new item called “Broken Access Control.” Another change is the dropping of item 10, “Unvalidated Redirects and Forwards,” which is still a risk but considered less of a problem than it was in 2013. With these two modifications, the OWASP Top 10 has room for two more items: “Insufficient Attack Protection” and “Unprotected APIs.”
These changes have generated a few unenthusiastic industry reactions, among them complaints that some of the new items are too broad or just plain unnecessary. OWASP, for its part, has done well in working through this feedback with a call for additional data and by extending the list’s release until November 2017. None of their work on the Top 10 is secret, so anyone is free to review and comment.
Beyond understanding the OWASP Top 10 security risks in relation to the web applications your organization builds and uses, what else should you be doing? There are a few simple steps you can follow to ensure long-term upkeep of OWASP issues.
1. Understand your OWASP scope.
OWASP is already part of numerous compliance requirements and contractual obligations. Review your legal agreements and regulatory environment to see what you might be legally obligated to do with OWASP. This may entail talking to your legal department and/or reviewing the contracts with them. There are numerous international security standards related to compliance that reference the OWASP Top 10, and you may fall under one or more of them. It’s better to know now than have an unpleasant surprise later.7
2. Scan all web applications.
Scan and test all the web applications your organization depends on against the OWASP Top 10. This means anything you’ve written and anything you use. If you’re using a third-party web application and depend on it, ask the vendor for a copy of their latest web application vulnerability test. If they don’t have one, speak to Legal about getting that requirement added to the next contract. If they haven’t done a scan, it’s likely they aren’t paying attention to vulnerabilities at all and that their application already has holes you don’t know about.
3. Share results.
Share your findings of the previous two steps with your company’s executive decision makers (at the very least, the CIO) as well as the development engineering team. Make sure your messaging is appropriate for each audience. Executives want to hear the bottom line regarding business risk and dependency, not technical detail. Developers want technical detail, especially the specific steps on how the vulnerability can be exploited and what an attacker can do with it.
4. Educate and inform.
Your web developers should be familiar with the OWASP Top 10, and OWASP Top 10 training may be contractually required by your company. Beyond telling the developers about the obligations and vulnerabilities you found, you should educate them on the entire OWASP Top 10 list. You can take this a step further and draft a security policy regarding web application security to help inform the entire technical and operational staff of its importance. Some of the key elements of such a policy can include:
- All Internet-facing web-based applications will be tested against the OWASP Top 10 vulnerabilities at least once a quarter.
- A secure coding standard based on industry best practices will be followed.
- Developers will have adequate security training in the OWASP Top 10.
- Developers will use threat modeling to look for common attacks, such as those described in the OWASP Top 10, to ensure their applications can defend against them.
- IT will ensure that test data, default accounts, and passwords are removed or changed when web applications are deployed live.
- Security vulnerabilities will be tracked, risk-reviewed, and fixed.
- Periodic reviews and auditing will be done against this policy.
5. Firewall what you can't fix.
Web application security can leverage specialized defensive tools, like web application firewalls that are specifically designed to analyze and block application attacks. They go beyond standard firewalls in that you program them to match the unique application requirements of your website. Some can also take data feeds from web application vulnerability scanners and do “virtual patches” by blocking previously uncovered but unmatched web vulnerabilities. The downside is that web application firewalls are complex and require customization to function correctly, but a lot of that work could be outsourced.
6. Become part of the OWASP community.
Join OWASP, attend a meeting, or, at the very least, review some of their material. The OWASP Top 10 is just a tiny part of the material generated by thousands of individuals and hundreds of companies over nearly two decades. There’s a lot of useful and inspirational material on their site.
Do you have issues with how the OWASP Top 10 list looks? Share your thoughts and contribute at https://github.com/OWASP/Top10/issues.
In general, the OWASP Top 10 falls into the category of “Basic stuff you should be doing so you don’t look negligent if you get hacked.” It represents the minimum level of web application security that you need to meet. Don’t get stung.
