The Open Web Application Security Project (OWASP) is one of the most respected sources of information regarding web application vulnerabilities. OWASP’s latest update to their Ten Most Critical Web Application Security Risks list was released in 2017. While there have been some significant changes, such as the merging of insecure direct object references and missing function level access control, using components with known vulnerabilities has remained untouched in the A9 position.
How Is a Web App Affected by Components With Known Vulnerabilities?
Without adequate protection or alternative security controls like a web application firewall (WAF), vulnerable components (i.e., third party frameworks, modules or components) are more than likely to be identified and exploited by cybercriminals, either manually or with automated tools. This means an attacker does not need a specific target — if 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 this sort of attack can be quite common, many applications and APIs remain exposed because 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 the 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.
What Is an Example of a Component With Known Vulnerabilities?
A practical example of this type of vulnerability is Heartbleed, a flaw in the OpenSSL cryptographic software library discovered in 2014. This software component, whose main purpose is to protect data on web applications, had a security weakness allowing attackers to steal the information usually protected by SSL/TLS encryption. This bug allowed anyone on the Internet to read the memory of systems protected by the vulnerable versions of the OpenSSL software, compromising secret keys used to identify service providers and encrypt the traffic, names and passwords of users and the actual content. By eavesdropping on communications, attackers could steal data directly or even impersonate the services or users. At the time this issue was discovered, half a million widely trusted websites were vulnerable to the Heartbleed bug. As of early 2017, a great number of companies (about 200,000) were still using a component with a known vulnerability.
Why Is Using Components With Known Vulnerabilities Still a Persistent Threat?
The Heartbleed bug was discovered in 2014, but still exposes a significant number of companies several years after the fix was released. Considering such examples, and this may apply to several other vulnerabilities, it stands to reason the technical aspect of the problem is just one factor. The major challenge here is deploying a process that ensures the continuous monitoring of components in use, both client-side and server-side, for new vulnerabilities and fixing found issues as soon as possible. This can be quite a difficult task, mainly because of the lack of standardization in vulnerability reporting. Discovering the exact component in a product family with a vulnerability is often 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 Can I Avoid Using Components With Known Vulnerabilities?
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. Once a vulnerable component is found, it is important to determine 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. This 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. Once a vulnerability is found, you must decide whether to update the component (and the best way to deal with rewriting application code if required) or use virtual patch technology that 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 using components with known vulnerabilities without proper care for security controls is not acceptable. Management should take the necessary efforts to ensure the security and development teams understand and adhere to secure development and vulnerability management best practices. This sounds a lot more complicated than it actually is. 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.
How Can I Learn More About Web Application Vulnerabilities?
Infosec Institute offers secure-coding training modules for developers through its security awareness training platform, SecurityIQ, including a module on known vulnerabilities. The platform includes training for every vulnerability included in OWASP’s 2017 list, as well as over 300 additional security awareness training modules for all employee levels and roles. Sign up for a free SecurityIQ account to get started today. Another great option is the OWASP Top 10 Boot Camp, an interactive experience focused on providing a good mix of engaging lectures, hands-on secure coding lab activities and group exercises. This is the most current, up-to-date and hands-on secure coding training available.
Sources
Half a million widely trusted websites vulnerable to Heartbleed bug, NetCraft Heartbleed: 200,000 websites and systems still vulnerable to OpenSSL bug, The Inquirer
