The OWASP is one of the main organizations –some would say the most important– dictating best practices in the Application Security world. Over time, many factors have contributed to the authority and credibility that this community enjoys, such as its independence from any technology vendors (as a non-profit), its technical credibility driven by a powerful community of computer science researchers, and the quality of its publications body.
In particular, the OWASP Top 10 Project (The Ten Most Critical Web Application Security Risks) is trusted as the bible of the most prevalent and exploitable vulnerabilities in the web application development space. The list has reached a level of popularity such that it is common practice to refer to the elements of the ranking by name, and even directly by its OWASP ranking code, when comparing protection solutions and assessing an application security vendor.
At Hdiv we take this document very seriously –certain Hdiv members print business card sized summaries to bring the ranking always with them– so we wanted to take some time to describe the main changes in the most recent edition of the Top 10, which replaces the previous edition, released in 2013.
We are happy to report that our range of products (Hdiv IAST detection, Hdiv RASP protection, and Hdiv verification) offer protection from 90% of the 2017 Top 10 risks.
In short, here is a quick list of the Top 10 risks, after which we will briefly highlight the changes introduced since the previous edition, and how Hdiv can help removing these and other common security threats.
2017 OWASP Top 10
- A1:2017 – Injection: when attackers force the application to insert and execute foreign code, producing database query results or actions that should never have been executed
- A2:2017 – Broken Authentication: when the session control instruments such as passwords, tokens, and keys are not properly protected
- A3:2017 – Sensitive Data Exposure: application data is handled in a way that can be extracted, including storage, transportation, and processing
- A4:2017 – XML External Entities (XXE): insecure handling of XML content
- A5:2017 – Broken Access Control: application features and domain data are not protected properly
- A6:2017 – Security Misconfiguration: umbrella that describes the insecure configuration of any of the elements of the application stack, from operating system and storage, to third party libraries
- A7:2017 – Cross-Site Scripting (XSS): make the application store and serve malignant code to its users
- A8:2017 – Insecure Deserialization: manipulate data sent to the app in a way that low-level object serialization does not behave as designed
- A9:2017 – Using Components with Known Vulnerabilities: the usage of existing libraries and/or frameworks with security flaws
- A10:2017 – Insufficient Logging & Monitoring: failure to quickly identify breaches
One of the changes that got our attention was the merging of the
Insecure Direct Object References (A4 vulnerability in the previous ranking) and the Missing Function Level Access Control (A7 vulnerability previously) into OWASP 2017-A5.
To put it simply, A4 referenced the manipulation of requests to access pieces of domain data that were off limits, and A7 referenced the manipulation of requests to access pieces of application functionality that were off limits. In particular, the “A4” had become one of the most sensitive talking points in application security conversations: we believe that the reason behind this popularity was the inherent difficulty of providing scalable, predictable, and automated response to this threat. After all, many security firms would confidently say that A4 is not really a vulnerability, but a complete responsibility of the application developer and her business logic.
According to Gartner this vulnerability is one of the most important examples of business logic flaws that can not be detect by AST (Application Security Testing) tools.
At Hdiv we believe that developers deserve better and can demand more from their application security framework, so we built the only RASP library that can provide full protection from the A5:2017 vulnerability, both from functional level threats, as well as domain data tampering. Pretty cool!
Another fundamental change introduced in the 2017 edition of the ranking is the addition of three new risks (A4:2017, A8:2017 and A10:2017) two of which were suggested by the community and vendors. The community voting process works by letting trusted developers voice their security concerns, of which more than 500 submissions were received for the 2017 edition.
A4:2017 or XML External Entities (XXE) risk concerns the way an application process XML input. In particular, this risks involves the usage of older XML processors to parse request data. Vulnerable processors can reference external entities that override the server security. OWASP recommends moving away from XML to other structured request formats such as JSON and REST.
A8:2017 or Insecure Deserialization is a technical risk that concerns how the application uses serialization either directly, or by using existing framework facilities. At a technical level, its philosophy relies primarily on a varietal of code injection that is surfaced when the affected piece of data is serialized.
As you probably know, serialization is a software engineering data manipulation technique that is used when a binary object needs to be “moved” out of memory to store it, and/or transmit it over a communication channel. For instance, Base64 encoding is a crude way of serializing a binary object. The risk arises when in the serialization phase, an attacker injects instructions in the serialized data in a very specific way, so that when the back-end processor deserializes the data, it executes with no control the code that the attacker inserted. A good example would be an attacker that modifies a cookie received from a web application to cause custom code execution in the server when the cookie is retrieved by the web application.
The bad news is that, at low-level, serialization can happen behind the scenes in multiple occasions during the lifecycle of complex systems, such as during load-balancing, persistence, or reliance on microservices architectures. Also, the potential impact of custom code execution is practically unlimited.
The good news is that so far the potential A8:2017 exploits are quite difficult to design, and must rely on another vulnerability to be successful. We believe that A8:2017 mitigation could be accomplished by a solid parameter validation (as in the more general injection case) accompanied by strict component validation (as in the more general risky component protection). However, a solid input validation is very difficult to implement correctly. Strict type comprobations, and signatures are ways to achieve this protection.
Hdiv Protection (RASP) offers protection for Insecure Deserialization attacks by default, detecting any attack that tries to execute remote code based on this vulnerability.
A10:2017 or Insufficient Logging & Monitoring is the other new addition to the 2017 ranking and it concerns the infrastructure put in place to detect any abnormal activity such as malicious attacks and actual security breaches. We are not surprised of seeing this “soft” risk emerging, as one of the main criticisms observed during the worst successful breaches of the last months has been the long time that the affected organizations took to flag and block the penetration.
As firm believers in the embedding of security as integral part of the DevOps activities (through the complete lifecycle of the application) we also welcome this addition as it concerns damaging habits that we often see in our clients. A common risky habit is the thinking that once an app has been developed and secure-tested, it can be considered safe and as so, forget about its monitoring. A10:2017 introduces the necessity of maintaining habits such as the effective reporting of warnings and the triggering of alerts when new zero-day vulnerabilities are discovered and documented by organizations such as the CVE registry. Hdiv offers a centralized monitoring web console providing real-time visibility into actual attacks. It logs actionable information about attacks and suspicious activity and sends alerts through several types of alert systems: email, syslog, Slack, etc. It is integrated with 3rd party systems, such as task management solutions (JIRA, Asana, EasyVista) and SIEM (Security Information and Event Management) systems, providing better management of detected incidents and a faster response to attacks.
Protection from the OWASP Top 10 risks
As applications become more widespread and complex, it is increasingly difficult to follow a “build” approach to offer protection from security threats. In the past, it used to be more common to delegate this responsibility to the core developing team, who would introduce security requirements as a regular business use case. Moreover, 2017 has seen a waterfall of severe breaches at very large and competent firms, from Uber and Experian, to more recently the Spectre vulnerability in technical powerhouses Intel and ARM.
At Hdiv we believe that application security should be something that it is largely provided to developers as an additional resource, and as part of any agile integrated development platform. In this philosophy, we have built a suite of products providing IAST detection, RASP protection, and verification (BURP suite extension) which work together as a single element to provide protection for our clients from 90% of the 2017 Top 10 risks and their associated vulnerabilities.
To get an immediate online demo, please click here.