Using third party libraries or frameworks is very convenient. With these external components, developments are made easier, the development team saves precious time, and usually benefits from an active community.
However, like any software or piece of code, third party components are not immune to web attacks. Worse, the more popular a component becomes, the more subject to attacks it is. Attackers use to focus on widely used components, on which attacks can be broadly launched.
When a security flaw is discovered on one of these components, the vulnerability usually becomes public, a patch is made available and web application developers are supposed to upgrade to the patched version.
The bad thing with this security policy is that attackers are looking for discovered vulnerabilities and exploit them as soon as available (within a few hours/days on critical components).
This kind of security flaw is ranked #9 on the OWASP Top 10 2013.
What kind of attacks?
The range of possible attacks is huge, and includes any type of attack, like SQL injection, XSS, authentication bypass… Any kind of flaw might be included in a piece of code.
Examples of this type of security issues are countless.
Recent examples could be Heartbleed and Drupal.
This flaw was affecting the OpenSSL library versions 1.0.1 to 1.0.1f and attackers could extract sensitive data from encrypted communications.
When it became public, the flaw has been exploited broadly, compromising loads of data.
Want to know more about this flaw?
A highly critical SQL injection vulnerability has been discovered and announced by Drupal security team.
Versions up to Drupal 7.31 are affected, and attackers can easily implement a backdoor on the system. The biggest problem with this vulnerability is that patching the system to 7.32 does not remove potential damages caused by an attack that could happen before patching.
How to prevent this?
The first thing to do if not already done on your web projects is to maintain a list of used third party components, and their versions.
This will help identifying potential vulnerable components and your development team can take action when necessary.
Then, putting in place some mechanism to monitor new versions and know vulnerabilities is essential.
Through projects mailing lists, security mailing lists and public vulnerabilities databases, developers can keep up-to-date and know what’s happening.
As an example, Drupal security team has a blog that you can follow:
You can also follow them on Twitter.
Disabling unused components is also important. If you don’t use a component in your web application, remove it. That’s one potential security flaw solved quite easily.
Why technical technical teams don’t manage this properly
Downloading and installing libraries, frameworks, components is easy, quick, and saves time.
But do not forget to properly manage these third party things, even if it takes time and can be quite boring.
That’s the price of open source components! (and an additional cost on commercial ones…)
Other articles in this series:
- Understanding web vulnerabilities in 5 min – episode #1: injections!
- Understanding web vulnerabilities in 5 min – episode #2: Hijacking!
- Understanding web vulnerabilities in 5 min – episode #3: XSS, Cross Site Scripting!
- Understanding web vulnerabilities in 5 min – Episode #4 – Insecure Direct Object References
- Understanding web vulnerabilities in 5 min – Episode #5 – Security Misconfiguration
- Understanding web vulnerabilities in 5 min – Episode #6 – Sensitive Data Exposure
- Understanding web vulnerabilities in 5 min – Episode #7 – Missing Function Access Control
- Understanding web vulnerabilities in 5 min – Episode #8 – CSRF Cross Site Request Forgery
- Understanding web vulnerabilities in 5 min – Episode #9 – Using vulnerable third party components
- Understanding web vulnerabilities in 5 min – Episode #10 – Unvalidated redirects and forwards