Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives  Connecting marketers to our tech communities.
09:00 AM
Raymond Pompon
Raymond Pompon
Partner Perspectives
Connect Directly

6 Steps to Finding Honey in the OWASP

The most famous project of the Open Web Application Security Project is getting an update. Here's what you need to know, and how you can get involved.

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 organization 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 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, says Internet Web Statistics. That doesn't count enormous numbers of bots trawling the web every day. According to Internet trend watcher Mary Meeker, there are currently more bots than humans viewing sites. 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. 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 10 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, here are six simple steps you can follow to ensure long-term upkeep of OWASP issues.

Step 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.

Step 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.

Step 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.

Step 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.

Step 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.

Step 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. 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.

If you have issues or questions about the proposed new OWASP Top 10 list, you can share your thoughts and contribute at the OWASP foundation forum on GitHub.

Get the latest application threat intelligence from F5 Labs.

Raymond Pompon is a Principal Threat Researcher Evangelist with F5 labs. With over 20 years of experience in Internet security, he has worked closely with Federal law enforcement in cyber-crime investigations. He has recently written IT Security Risk Control Management: An ... View Full Bio
Comment  | 
Print  | 
More Insights
Oldest First  |  Newest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/21/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. x86 PV guest kernels can experience denial of service via SYSENTER. The SYSENTER instruction leaves various state sanitization activities to software. One of Xen's sanitization paths injects a #GP fault, and incorrectly delivers it twice to the guest. T...
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that an event channel, once valid, will not become invalid over the life time of a guest. Howeve...
PUBLISHED: 2020-09-23
An issue was discovered in Xen 4.14.x. There is a missing unlock in the XENMEM_acquire_resource error path. The RCU (Read, Copy, Update) mechanism is a synchronisation primitive. A buggy error path in the XENMEM_acquire_resource exits without releasing an RCU reference, which is conceptually similar...
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. There are evtchn_reset() race conditions. Uses of EVTCHNOP_reset (potentially by a guest on itself) or XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the violation of various internal assumptions. This may lead to out of bounds memory a...
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. Out of bounds event channels are available to 32-bit x86 domains. The so called 2-level event channel model imposes different limits on the number of usable event channels for 32-bit x86 domains vs 64-bit or Arm (either bitness) ones. 32-bit x86 domains...