Open-source application security flaws: What you should know and how to spot them

Introduction

Open-source software helped to revolutionize the way that applications are built by professionals and enthusiasts alike. Being able to borrow a non-proprietary library to quickly prototype and build an application not only accelerates progress in projects, but also makes things easier to work with.

Open-source libraries when creating applications is not the only positive aspect of open-source software. Finished open-source applications are everywhere on the internet. Almost every commercial version of software has an open-source competitor that performs almost the same functions, making open-source programs very popular and in most cases, free.

This popularity has led to an uptick in open-source software usage. This is great if the software project you have chosen has used proper security practices when writing the application, but if any security flaws went unnoticed, then the end user may have a problem. Veracode recently revealed that out of 85,000 applications that it scanned for, 70% had vulnerabilities present. This means that many of the seemingly harmless applications that you have been using might not be as safe as you thought.

What are security vulnerabilities?

The term “security vulnerability” gets used a lot in the modern world of software design, and with good reason. Almost everything is connected and programmed to communicate over the internet these days, which means that if your application has a security vulnerability then you might have unwanted people connecting to your system, intercepting your data or infecting your computer and network with malware.

Not all applications are created equal, though. The report says that JavaScript applications seem to lean the most on third-party and open-source libraries. Many attack vectors can be used with JavaScript, and this massive reliance on so many libraries is definitely a concern. But that is not to say that JavaScript is the only offender.

That same report went on to outline many other programming languages and frameworks were also using less than secure libraries in their projects. PHP and Swift are two such examples that need work on the security front and have a higher probability of using an insecure library.

Common types of vulnerabilities

There are many different types of vulnerabilities that an application could be susceptible to if proper security controls are not introduced right from the development stages of a project. OWASP (Open Web Application Security Project) is a great source for current threats and vulnerabilities that are affecting modern software applications, sites and web apps. The report references quite a few of these OWASP Top 10 vulnerabilities. 

From the list of OWASP threats, the report was able to give us a useful breakdown of which vulnerabilities were detected. From smallest to largest, the report found that Security Misconfiguration causes just 0.6% of issues from their sample pool. Next was XML External Entities, or XXE for short, which saw a prevalence of 2.7%. Next, we see Broken Authentication with 7.4%, Sensitive Data Exposure at 7.8% and Injection showing up in 8.8% of samples.

The top three security flaws were present in three out of every four flaws found in the scanned libraries, which is of real concern. Broken Access Control was responsible for 20.3% of instances, Insecure Deserialization 23.5%, and the most common out of all of the security flaws was Cross-Site Scripting (XSS).

Each of these flaws can be dealt with before a product gets released, and we outlined many of these solutions in a previous article if you would like to learn more.

Is there a way forward?

Although the report does paint a rather dark picture of the current state of open-source software vulnerabilities, there are things that you can do right now to minimize your risk. Ultimately it is up to the developers to resolve security flaws deep in the core libraries of their software, but you can keep an eye on your apps to make sure that things are working as they should.

1. Secure your base system: This means that whatever device you use to run open-source applications — be it a laptop, desktop computer or even a smartphone — it needs to be updated and patched as often as possible. Many vulnerabilities in applications can be stopped dead in their tracks if your main operating system has been patched.
2. Antivirus and anti-malware: This sounds like a cliché, but if you are connecting to the internet then you need some kind of malware defense. If an open-source application is unwittingly hosting malware or trying to contact the command-and-control site, then you need to take preventative measures.
3. Be vigilant: If you are running open-source software, then keep an eye on its behavior. Are you noticing any strange spikes in network behavior like increased traffic or high memory or CPU usage? If the answer is yes while running your application, then you will need to check if others are experiencing similar issues. Chances are that you are not alone.
4. Update your apps: Sometimes a developer will include a library that they thought was secure and unintentionally opened their own users up to a threat. Most projects under active development will have regular updates to such libraries, so if you are aware of an issue with your particular application, then be sure to update. In a worst-case scenario, a project that finds out that problematic libraries are part of the software can have them written out of the source code and replaced with a different one entirely.
5. Create your own alternative: Open-source software makes it possible to share and change the software however you see fit. The only limitations are the license issued with the application itself and your technical abilities. Most open-source software agreements allow you to make changes to the source code as long as you follow the agreement that it was issued under. Perhaps the most widely recognized license of this kind is the GPL, or GNU Library Public License that is common in many Linux systems and applications.

Trust, but verify

You may already be using an open-source software application that is vulnerable to certain exploits, or you might be thinking about adopting a useful application that could help you in your day-to-day workflow. Before you jump in, try to establish whether there are any known vulnerabilities in the associated libraries of the project or if the application itself has any known bugs that affect security. If you prefer to check for yourself, then you can use tools to inspect software dependency vulnerabilities.

OSSIndex

OSSIndex is a tool that lets you view the contents of packages found commonly in environments like Linux and Nugent, as well as Chocolatey and MSI packages. The vulnerability API that it uses can find vulnerabilities. OSSIndex is looking to implement automated processes in the near future, which will allow you to create seamless testing routines to scan for vulnerabilities.

NSP

The Node Security Project focuses primarily on Node.js modules and any NPM dependencies of these objects. The tool allows developers to scan for both vulnerabilities and dependencies via the NIST NVD database, which can show you if there are any security concerns. If they are discovered in the module, then you will know about it.

RetireJS

RetireJS is a tool that focuses on JavaScript projects and software. It is very user-friendly and provides components such as a command-line interface that can scan plugins for applications and popular internet browsers such as Chrome and Firefox. They also have a tool for checking websites for vulnerabilities so that JavaScript libraries with a documented or identified threat can be spotted.

Conclusion

Now that we know what the vulnerabilities are for open-source projects, where do things stand? Open-source software is not going anywhere any time soon. This means that if you or your company are thinking about employing open-source applications, or developing an application that uses open-source libraries, then you need to be cautious. 

There are many ways to approach the risks present in some of these libraries. If you are thorough with your research and you know exactly what the application consists of, then you are in a better position to safeguard yourself against potential issues.

Source

Open source libraries a big source of application security flaws, Naked Security