#### The Journey to the New and Improved Ten Most Critical Web Application Security Risks

It was not too long ago that protecting your web server infrastructure consisted of simply placing the server(s) in their own zone behind the firewall and just opening a couple of ports. Outside of endpoint protection, that was pretty much the formula. That however was in a static HTML world. Today, thanks to the fruition of the web application and how it allows users (and hackers) to dynamically interact with it, security is far more complicated. Nearly every major company and organization that deals with high value data has some sort of web application presence today, supported by a highly complex technology stack.

Image Licensed under Creative Commons

As Internet complexity evolved, web application based sites moved to use a three-tiered application stack, with each tier needing a different security approach.

Fast forwarding to the present, most applications are modular and use containerized micro-services, complex data and metadata types and external SaaS utilities in addition to the traditional applications layers. This complex architecture means that in addition to the north-south traffic pattern between the user desktop and the client tier, (the front-end HTML server) the site creates a large degree of east-west traffic amongst the multiple servers residing in these separate tiers. This additional traffic highway, along with the added complexities in design make cyber security that much more difficult. Now add the rapid pace of software development processes and the integration of DevOps and one begins to recognize how application security has evolved from 2010 to 2017.

### The Open Web Application Security Project (OWASP)

The Open Web Application Security Project (OWASP) is an open community dedicated to the mission of enabling companies to develop, purchase, and maintain applications and APIs that can be trusted. One of the key projects of OWASP is determining the most critical web application security risks, so called Top Ten. It is based upon the culmination of 11 datasets from firms that specialize in application security and spans vulnerabilities gathered from hundreds of organizations and over 50,000 real-world applications and APIs. Since 2003, OWASP has been releasing a list of the 10 most prevalent application security risks every few years. The purpose of the OWASP Top 10 is to build awareness of the most common exploits that hackers use to infiltrate and compromise data within web based applications. As a result, it has become an unofficial industry standard that guides and directs the security approach of many companies today and serves as a staple for many vulnerability testing product-scoring mechanisms.

Wallarm is a proud member of OWASP. We support both the local Silicon Valley chapter and the wider OWASP organization.

Also, come see Wallarm at [AppSec CA 2018](), which we are sponsoring.

OWASP Top 10–2017. Copyright © OWASP

### OWASP 2017 – The Journey

Released in April 2017, RC1 of the new revision of the Top 10 had relatively few changes compared to OWASP Top 10 most critical web application security risks circa 2010, the were listed as follows:

* A1 — Injection
* A2 — Broken Authentication and Session Management
* A3 — Cross-Site Scripting (XSS)
* A4 — Broken Access Control
* A5 — Security Misconfiguration
* A6 — Sensitive Data Exposure
* A7 — Insufficient Attack Protection
* A8 — Cross-Site Request Forgery (CSRF)
* A9 — Using Components with Known Vulnerabilities
* A10 — Under protected APIs

After its release however, Release Candidate 1 (RC1) became the focus of hot debate within the security community. It’s worth noting that with the 2017 Top 10 the process has significantly changed from that of the previous iterations. The main differentiators are the substantial community feedback and possibly the largest amount of data assembled from dozens of organizations. The data included 40+ data submissions from firms that specialize in application security and an industry survey that was completed by over 500 individuals. This data spans vulnerabilities gathered from hundreds of organizations and over 100,000 real-world applications and APIs.

After the first round of debates, it was decided to remove A7 — Insufficient Attack Protection, and A10 — Under-protected APIs from the list. At the same time, the community has suggested two new issues that were not previously a part of the Top 10 2017 A8-Insecure Deserialization and A10-Insufficient Logging and Monitoring. The need to address insecure desentralization directly stems from the microservices application architectures we talked about earlier. Ironically, the retraction of A7 coincided with the announcement by Equifax of the massive breach they experienced, putting into question whether A7 should have been retracted at all. In the final revision, A7 was combined with A4 to form A5- Broken Access Control.

Another new issue in the Top 10 is A4 — XML External Entities. This is the only new issue of the set which was introduced based on the direct data evidence from the security issues database. As we mentioned earlier, complex data structures and metadata are prevalent in the modern web apps. In addition to XML-based API protocols such as WSDL, SOAP and others, XML is the language of choice for metadata of everything, from movies to docker containers. Moreover, within the single applications, several daisy-chained XML interpreters may exist, depending on which tier of the application processes which part of the data. This potential ability to inject external, potentially executable, data in various points in the application stack via an XML interpreter is what makes XXE so dangerous.

On the other hand, XXS, that was the biggest danger to the websites for years, has been downgraded to A7. This can be mostly attributed to how well next generations WAFs and other defense tools can now protect from this vulnerability.

As for A7 and A10, they will now be added to the OWASP Top 10 Proactive Controls, which was first released in 2016. This list includes a list of security techniques that developers should incorporate into the development of all software. The List is shown below:

* Verify for Security Early and Often
* Parameterize Queries
* Encode Data
* Validate All Inputs
* Implement Identity and Authentication Controls
* Implement Appropriate Access Controls
* Protect Data
* Implement Logging and Intrusion Detection
* Leverage Security Frameworks and Libraries
* Error and Exception Handling

The old saying, the more things change the more they stay the same, is clearly applicable when comparing the OWASP Top 10 Security Risks over the years. If we look at the Top 5 risks for the past three lists, we see great similarity amongst them.


Many of the outlined risks fall under the responsibility of developers. A prime example is Injections, which tops all three lists. This threat involves untrusted SQL, OS, and LDAP data being sent as part of a command or query to the backend database. The attacker’s injected hostile data can result in the execution of unintended commands, allowing the intruder to access data without proper authorization. These type of attacks are usually the result of the absence of input validation (only allowing certain characters or commands within a text box or other input point).

Not all of the OWASP Top 10 are the result of improper programming techniques however. Many aspects of A6- Security Misconfiguration usually fall under the jurisdiction of the server or network administrator. Combatting this risk entails good security hygiene and a repeatable application security configuration process that includes

* Keeping all software including the OS, web applications, DBMS applications and code libraries fully patched an up to date
* Disabling or uninstalling unnecessary features, ports, services, accounts and privileges — for example the best way to address XXE is to disable external data feature in all XML interpreters.
* Changing all default accounts and passwords
* Disabling directory browsing on all web servers

These security measures will help solidify the protection of your API structures, as well as the enterprise at large as well. The fact is that all types of cybersecurity breaches continue to occur due to the same reasons. In addition to using the OWASP Top 10 to direct your security efforts, any organization that utilizes any type of web applications should implement regular vulnerability testing as well. For more information on OWASP and the 2017 Top Ten, you can[ click here]().


* * *

[OWASP Top 10 2017 is Released]() was originally published in [Wallarm]() on Medium, where people are continuing the conversation by highlighting and responding to this story.Read More