Part 1 of this series introduced the importance of small business (SMB) to make sure that their web-based apps are created and run using secure source code. Remember, the Cyberattacker of today is not just going after servers and firewalls. They look for any possible way to get in, including finding backdoors and other weaknesses in the source code. Now we will continue with this topic and provide recommendations for avoiding this kind of situation.
The security vulnerabilities of software development libraries
SMBs that make use of Development Libraries often fail to allocate the sources necessary to run audits on the source code. The bottom line is that “. . . everyone seems to think that someone else will find the vulnerabilities and what is published is secure.” 1
It has even been discovered that by using a Development Library, an average of 24 vulnerabilities are introduced into the source code, 40% of which are deemed to be critical.1
There are several reasons why Development Libraries have so many vulnerabilities:
- The old source code which is being used is not up-to-date.
- Routine audits are not conducted on the source code.
- An inaccurate Bill of Materials is maintained by the SMB.
- SMBs are reluctant to expend the extra resources needed to triage any vulnerabilities or weaknesses which may be discovered in the source code.
Examples of security flaws
The following are examples of security flaws that have been discovered:
- libssh: This flaw allowed for an end user to completely bypass the entire authentication process, and gain access to a development server without the need for a password.
- Org X Server: This vulnerability allowed a Cyberattacker to launch any line of arbitrary source code using unauthorized root privileges. Mission critical files had the potential to be overwritten, by making use of the “-logfile” and “-modulepath” parameters. Also, other rights and privileges could be quickly escalated by end users that had lower level access rights.
- Xmlseclibs: The weakness that was discovered allowed an end user to gain unauthorized access to encrypted XML documents that were digitally signed. As a result, any XML syntax could be maliciously altered.
- Requests: This type of Development Library is used heavily in Python coding environments. The flaw that was discovered sent HTTP Authorization Headers to a specific URL when the same-hostname https-to-http redirects were being used. This allowed for a Cyberattacker to covertly obtain login credentials.
How to avoid vulnerabilities found in software development libraries
There are three proactive measures that an SMB can take to avoid vulnerabilities in software development libraries:
- Create and implement strict Security Policies: The software development team must work hand in hand with the IT Security staff to test the source code. This is to ensure that any security weaknesses which are found are mitigated before the app goes into a production environment.
- Keep an updated inventory of what is being used: The SMB should create a centralized repository dedicated to the exclusive storage of the Software Development Libraries. Any security-related patches and fixes can then be efficiently applied in one location.
- Conduct tests on a regular basis: The IT Security staff should create and maintain a regular schedule for testing the Software Development Libraries to check for any backdoors that are left behind. One way to do this is by using the numerous testing tools which are available. Some of these testing tools:
- Retire JS: This has been specifically designed for testing JavaScript. It also has plugins which can be used for Mozilla Firefox and Google Chrome.
- OSSIndex: This can be used for testing not only JavaScript, but also .NET and C# development environments as well.
- Dependency-check: This tool was created for conducting security tests on Ruby on Rails development environments.
- WhiteSource: This tool can check for security weaknesses for PHP and Python.
The illustration below 2 depicts some of the best practices an SMB should implement to ensure that the Software Development Libraries they utilize are free from any security gaps or vulnerabilities:
References:
- https://www.computerworld.com/article/2864053/hey-devs-those-software-libraries-arent-always-safe-to-use.html
- https://connect.aricent.com/2018/05/third-party-libraries-when-the-angel-becomes-the-devil/
Ravi Das is an Intermediate Technical Writer for a large IT Services Provider based in South Dakota. He also has his own freelance business through Technical Writing Consulting, Inc.
He holds the Certified In Cybersecurity certificate from the ISC(2).