For over a decade, the Open Web Application Security Project (or OWASP for short) became one of the most respected sources of information regarding web application vulnerabilities. OWASP’s latest update on the “Ten Most Critical Web Application Security Risks” was released in 2017, and while there have been some significant changes, such as the merging of Insecure Direct Object References and Missing Function Level Access Control, the introduction of new arrivals like Insufficient Attack Protection / Underprotected APIs and even Unvalidated Redirects and Forwards being completely dropped out, Using Components with Known Vulnerabilities has remained untouched at the A9 position.
So, how can a web application be affected by Using Components with Known Vulnerabilities?
Without adequate protection or alternative security controls like a WAF (web application firewall), vulnerable components (i.e. third party frameworks, modules or components) are more than likely to be identified and subsequently exploited by cybercriminals, either manually or with the aid of one of several automated tools. This means that an attacker does not need a specific target, whether the search for a weak component is completed by automated scanning or performed by manual analysis, it is only a matter of time and persistence until a vulnerable application is found. While that this sort of attack can be quite common, many applications and APIs remain exposed due to the simple fact that development teams do not ensure their components and libraries are up to date. In extreme cases, developers may not even be aware of all the components (or their versions) they are using. In this scenario there is a great deal of weaknesses that can be exploited, including injection attacks, bypassing access controls, and XSS. The impact of a successful attack can vary from a minimal nuisance to a complete takeover and major data exposure, so depending on what the application is used for, this can either be something trivial or a significant compromise to the business. A practical example of this type of vulnerability was a flaw in the OpenSSL cryptographic software library discovered in 2014. Ironically enough, this software component, whose main purpose is protecting data on web applications, had a security weakness that allowed stealing the information protected under normal conditions by the SSL/TLS encryption. This bug allowed anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software, compromising secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. By eavesdropping on communications, attackers could steal data directly or even impersonate the services/users. At the time this issue was discovered, half a million widely trusted websites were vulnerable to the Heartbleed bug[1], and as of early 2017, a great number of companies (about 200,000) were still using a component with a known vulnerability[2].
Why is this still a persistent threat after all these years?
The one question that comes to mind is why is this still a persistent threat after all these years? As mentioned before, the Heartbleed bug was discovered in 2014, but still exposes a significant number of companies several years after a fix was released. Considering such examples, and this may apply to several other vulnerabilities, it stands to reason that the technical aspect of the problem is but one factor. The major challenge here is deploying a process that ensures the continuous monitoring of whatever components are being used, both client-side and server-side, for new vulnerabilities and proceeding to fix any issue as soon as practical. This can be quite a difficult task, mainly because the lack of standardization of vulnerability reports, turning the efforts of discovering the exact component in a product family that has a vulnerability into a very difficult and time-consuming endeavor. To make matters worse, several vulnerabilities can remain in the shadows, since they may never get properly reported to the Common Vulnerabilities and Exposures (CVE) or the National Vulnerability Database (NVD) repositories.
How to avoid ‘Using Components with Known Vulnerabilities’
As mentioned before, the best approach to resolving A9 issues is creating a systematic process to both identify and treat any vulnerability that may affect a web application. While some companies may have teams that will try to find weaknesses manually, in most cases the process is performed with the aid of automated tools such as vulnerability scanners. Ideally a combination of both automatic analysis and manual inspection should be in place, for instance once a vulnerable component is found, it is always important to be sure whether the application using it is in fact vulnerable. This may require checking the code to confirm if the vulnerable part of the component is actually in use, and how this flaw could impact the application/business. While using automated tools can drastically reduce the time required to discover weak components, the reports generated can be quite vague, so validating vulnerabilities is a task best performed with the help of an expert professional. Once a vulnerable component is confirmed to be in use, the usual remediation plan is updating it to the latest version, which can create another problem: Most of the time it will require code changes to the affected application. Now, if a business has a development team available, it is just a matter of allocating resources, but since many companies will simply buy a web application from a third party developer, they may not have the necessary assets for implementing code updates right away. To avoid these issues, it is imperative that software projects have a process in place to continuously inventory the versions of both client-side and server-side components and their dependencies, and once a vulnerability is found, a strategic decision must be taken decide to whether to update the component (and the best way to deal with rewriting application code if required) or using virtual patch technology, which can analyze HTTP traffic, data flow, or code execution and prevent the exploit of vulnerable components. Whatever approach your company is enforcing, it should make clear that using components with known vulnerabilities without proper care for security controls is not acceptable. Management should take the necessary efforts for evolving both the security and development teams to understand and adhere to secure development and vulnerability management best practices. This sounds a lot more complicated than it actually is, and since it is the only practical way of guaranteeing a proper level of protection for web applications, any alternative method will expose your web application to an unknown level of risk that may severely impact company operations, reputation and finances. The Infosec Institute has several options for growing skills at a fast pace. For instance, Security IQ is the perfect online learning platform, providing dedicated modules to each of the OWASP Top 10 Web Application Security Risks. Still unsure? Why not try it? Enrolling can be done in a matter of minutes, and the ‘Personal’ membership option allows up to ten learners to check for the basic functions of Security IQ. Another great option is our OWASP Top 10 Boot Camp, a unique experience focused on providing a good mix of attention-getting lectures, hands-on secure coding lab activities, and engaging group exercises. There is no doubt about it: This is the most current, up-to-date hands-on secure coding training. We take pride in providing the opportunity to learn from the very people who do it: Our instructors are active and expert developers, with proven field experience in secure coding. Our track record says it all: We have trained more developers in secure coding courses than any other training company. [1] Source: https://news.netcraft.com/archives/2014/04/08/half-a-million-widely-trusted-websites-vulnerable-to-heartbleed-bug.html [2] Source: 200,000 websites and systems still vulnerable to OpenSSL bug.
