2017 OWASP Top 10 for PHP Developers Part 9: Using Components with Known Vulnerabilities

Attacks on today’s web are an unsurprising reality – websites are hacked daily, data is being stolen and leaked left, right and centre. In many (though not all) cases, attacks on web applications are successful because a targeted web application is susceptible to security vulnerabilities – vulnerabilities which derive from its components. In the penultimate segment of the 2017 OWASP Top 10 series, I will cover how using components with known vulnerabilities can affect your web application, tell how such risks are exploited in the wild and explain why it is an issue that needs attention.

Defining using components with known vulnerabilities

This risk is really as simple as it sounds – it is such a security vulnerability that derives from using components with known security vulnerabilities. Here’s how OWASP summarises the flaw:

Threat Agents / Attack Vectors		Security Weakness		Impacts
App Specific	Exploitability: 2	Prevalence: 3	Detectability: 2	Technical: 2	Business: ?
While it is easy to find already-written exploits for many known vulnerabilities, other vulnerabilities require concentrated effort to develop a custom exploit.		Prevalence of this issue is very widespread. Component-heavy development patterns can lead to development teams not even understanding which components they use in their application or API, much less keeping them up to date. Some scanners such as retire.js help in detection, but determining exploitability requires additional effort.		While some known vulnerabilities lead to only minor impacts, some of the largest breaches to date have relied on exploiting known vulnerabilities in components. Depending on the assets you are protecting, perhaps this risk should be at the top of the list.

How to determine whether a web application is vulnerable to this attack?

This is a question that will inevitably be asked and such a question is hard to answer precisely, but honestly, if your web application is running software of some kind, it most likely is. WordPress is a perfect example – the majority of data breaches regarding it are possible because web developers use third-party add-ons that contain security vulnerabilities. Third-party features and plugins are great – they can extend the functionality of the system that is being used; the problem is, however, that in many cases, new features introduce new security vulnerabilities. In order to know if your web application is susceptible to this issue, ask yourself these questions:

1. Do you update the components of your web application? How often do you do it?
2. How many components does your web application use? Are all of them necessary?
3. Do you regularly scan your code for vulnerabilities?
4. Do you regularly read security reports related to the web application components you use?

 

1. Updating your web application components is crucial. When updates are delivered, they often patch security flaws and in many cases, enchance the user experience – if a web application falls out of date patch-wise, it’s only a matter of time before it gets compromised. If you’ve never bothered to update, do it now.
2. With more features, your web application also becomes susceptible to more security vulnerabilities. It’s hard to tell what vulnerabilities will be introduced, as this heavily depends on the web application and its components, but given the fact that the impact of web application vulnerabilities being exploited can be severe, web developers should only use those components that are necessary to keep a web application running smoothly and to narrow down the scope of objects that can be of value to a potential attacker.
3. By regularly scanning code for potential vulnerabilities like SQL Injection (SQLi), Cross-Site Scripting (XSS), Remote Code Execution (RCE), Directory Traversal or any other known security issues and patching them as soon as they occur web developers can minimise the chances of getting their web application compromised. Now simply scanning code for vulnerabilities does not mean that vulnerabilities will be found, however, it is a good security measure.
4. By subscribing to security bulletins related to the web application components in use, web developers can stay on top of emerging web application security threats that may harm their web application.

Of course, there are other measures that could be taken, I’ve only listed a few of them.

How would an attack look like?

For a second, imagine that your web application is susceptible to this security vulnerability. As a security conscious web developer, you are probably wondering how would a nefarious party attack your web application? The answer is, it depends – because this risk is non-specific (your web application could become vulnerable to all sorts of flaws which might be exploited in all sorts of ways – it all depends on what web application components you use and what vulnerabilities they have), it’s hard to comprehensively demonstrate, but consider this:

1. Is your web application running a content management system that is known to have been vulnerable in the past (vBulletin, MyBB, IPBoard, WordPress, Joomla etc.)?
2. Is your web application running on a third-party infrastructure provided by an enterprise?
3. Did you develop your web application yourself?

 

1. Have a look at security bulletins and exploit proof-of-concepts related to your CMS in order to get a clue of how your web application might be attacked and what consequences an attack may have.
2. Before choosing an enterprise that may be the core of your web application, ask them the questions you’re concerned about. Google them and do your research. You can even consider visiting their headquarters (if they have them) and talking with their team in person if you feel that would work best for you.
3. If you developed your web application yourself, make sure you did your research, used only the components that are a necessity to keep your web application up and running, and did your best to protect it against both prevalent and emerging web application threats.

You completed all points I’ve mentioned above – your web application is no longer vulnerable to this security flaw! Yes, I’m kidding, because that’s not how it works. In most cases (including this one), web security comes down to risk mitigation. I’ve said it before and I will say it again: there is no such thing as 100% security. Security can (and should) be hardened though, which brings me to the next point…

Do use web application firewalls

Web application firewalls are a great additional layer of defense – WAF’s can be put in front of your web application, understand when it’s getting attacked, and halt exploitation attempts. They are dead easy to implement too, thanks to WAF-as-a-service solutions. With that mentioned, none of this is to say Web Application Firewalls should be a justification for writing vulnerable code – they should be used as an additional layer of defense, not as an excuse for writing unsafe code without thinking about the consequences such actions might bring. Oh, and if you’re about to use a firewall (or are already using one) actually utilize the features available and log the rule violations (meme by Jack Rhysider):

Summary

Usage of components with known vulnerabilities is a very widespread and serious issue. While the explanation how to overcome such a flaw could be pretty obvious (web developers should not use components that are known to have vulnerabilities), the completion of such a task nowadays is close to impossible.

It is pretty hard to arrive at the description of what should you do in order to avoid this vulnerability being introduced to your web application (chances are your web application is already susceptible to it), but some general tips you can takeaway include knowing what components your web application is using, only using those components that are necessary, utilizing a web application firewall in order to reflect some of the web application security threats and frequently checking security bulletins such as the CVE (Common Vulnerabilities and Exploits) database and the Exploit-DB.