Today's Web applications are no longer the work of a single developer nor of a single development team; nowadays developing a functional, user-friendly, attractive-looking Web application implies the use of third-party components, such as programming libraries, APIs to external services (Facebook, Google, Twitter), development frameworks, and many other components in which programming, testing, and patching have very little or nothing to do.
Sometimes these third-party components are found vulnerable to attacks and they transfer those vulnerabilities to our applications. Many of the applications that implement vulnerable components take a long time to be patched, representing a weak spot in an entire organization's security. That's why OWASP classifies the use of third-party components with known vulnerabilities as the ninth most critical threat to a Web application's security.
In this recipe, we will see where to look to figure out if some component that we are using has known vulnerabilities and will look at some examples of such vulnerable components.
- As a first suggestion, prefer a known software which is supported and widely used.
- Stay updated about security updates and patches released for the third-party components your application uses.
- A good place to start the search for vulnerabilities in some specific component is the manufacturer's Web site; they usually have a "Release Notes" section where they publish which bug or vulnerabilities each version corrects. Here we can look for the version we are using (or newer ones) and see if there is some known issue patched or left unpatched.
- Also, manufacturers often have security advisory sites, such as Microsoft: https://technet.microsoft.com/library/security/, Joomla: https://developer.joomla.org/security-centre.html, and Oracle: http://www.oracle.com/technetwork/topics/security/alerts-086861.html. We can use these to stay updated about the software we are using in our application.
- There are also vendor-independent sites that are devoted to informing us about vulnerabilities and security problems. A very good one, which centralizes information from various sources, is CVE Details (http://www.cvedetails.com/). Here we can search for almost any vendor or product and list all its known vulnerabilities (or at least the ones that made it to a CVE number) and results by year, version, and CVSS score.
- Also, sites where hackers publish their exploits and findings are a good place to be informed about vulnerabilities in the software we use. The most popular are Exploit DB (https://www.exploit-db.com/), Full disclosure mailing list (http://seclists.org/fulldisclosure/), and the files section on Packet Storm (https://packetstormsecurity.com/files/).
- Once we have found a vulnerability in some of our software components, we must evaluate if it is really necessary for our application or can be removed. If it can't, we need to plan a patching process, as soon as possible. If there is no patch or workaround available and the vulnerability is one of high impact, we must start to look for a replacement to that component.
Before considering the use of a third-party software component in our application, we must look for its security information and see if there is a more stable or secure version or alternative to the one we intend to use.
Once we have chosen one and have included it in our application, we need to keep it updated. Sometimes it may involve version changes and no backward compatibility, but that is a price we have to pay if we want to stay secure, or the implementation of a WAF (Web Application Firewall) or an IPS (Intrusion Prevention System) to protect against attacks if we cannot update or patch a high-impact vulnerability.
Apart from being useful when performing penetration testing, the exploit download and vulnerability disclosure sites can be taken advantage of by a systems administrator to know what attacks to expect, how will they be, and how to protect the applications from them.