Very few web application projects are delivered using software completely written from scratch. Rather the modern application development model relies on frameworks, modules and components from various sources that are combined with custom written code to deliver the final product. Both commercial and free open source software components are regularly included in web application development projects. This approach makes sense. It means developers don’t have to write all the code needed to deliver the project. It also means that they don’t have to be experts in connectivity to the many external systems that modern web applications need to communicate with.
However, with these developer benefits come a few downsides. As a result of this approach to software development the popular third party components are very widely used. This means that they are known to anyone looking to attack a web application, and that any vulnerability discovered provides a rich target to exploit. Additionally many of the frameworks, modules and components that are incorporated into web application projects often run with raised privileges. A vulnerability in one of them can often provide access to other secure code and data within the application.
What is the vulnerability?
The actual vulnerabilities associated with third party frameworks, modules and components are as described in the other articles in this OWASP Series. Make sure you read the other articles for details and advice on how to mitigate them. The Using Components with Known Vulnerabilities OWASP top 10 entry emphasises the fact that third party software libraries have flaws. Two recent examples of software components that are well known, and have been widely used for years, that turned out to have flaws are:
- OpenSSL library. A software component often used to help secure data used by web applications. In 2014 the Heartbleed bug was discovered in OpenSSL. This bug allowed data encrypted with the SSL/TLS routines in OpenSSL to be compromised. It’s since been fixed. Update your OpenSSL if you haven’t yet!
- BASH Unix shell. The venerable BASH shell, that has been in use for two decades, was discovered in 2014 to have vulnerabilities that allowed command line injections to execute commands. These were dubbed Shellshock. The BASH shell has since been patched to address the issues. Again, update BASH if you haven’t done so recently.
These examples are not given to single out these two pieces of software, rather they illustrate that even software that has been in use for a long time can contain vulnerabilities. All software does. It’s how we deal with these that is important.
How to protect against this vulnerability
The examples given above both state that the vulnerabilities have been fixed and that you should update to the latest version. This is a general principle. Keep frameworks, modules and components up to date. Ensure that the latest patches are installed. Maintain a non-production system to test the patches. As an aside; have a split between Dev, Test and Live environments with easy ways to move new code from Dev to Test to Live during your testing process.
Another important tactic in guarding against vulnerabilities in third party frameworks, modules and components is to only use the parts that you need to deliver the application or service. Disable those parts you are not using. This is especially true if you are using a large application framework that has lots of functionality. It’s also a good idea to hide the framework you are using. If an attacker doesn’t know what software components you are using for your web application then they can’t target known vulnerabilities. One way to do this is to obfuscate URL’s so that they don’t contain paths and references that are identifiable as from a particular framework.
It’s also important to stay up to date with supplier security bulletins, project blogs, release notes, and with the information published on trusted security sites. It can be hard to keep on top of all the information that is published and discussed in relation to security. One approach that often helps with this is to adopt a DevOps collaboration model within your organisation. Doing this helps ensure that information about vulnerabilities is shared amongst team members in different departments. People have different interests and often read and keep up to date via different sources. Fostering an environment where people share information can really help bring known vulnerabilities to light. Make sure silos don’t prevent known vulnerabilities in a component of an application being shared between groups.
Deploy the KEMP Web Application Firewall Pack (AFP) for LoadMaster. This includes tools that continuously monitor requests to web application servers. It detects and counters known vulnerabilities, including those outlined by OWASP. The AFP pack is updated constantly by KEMP security experts so that vulnerabilities developers and system administrators may not have heard about are countered. Often before they know there is a newly discovered vulnerability they need to worry about.
You should do internal security audits and penetration tests. Regular audits should be done to make sure that the frameworks, modules and components that are in use in your web applications are the latest versions. If not test the new versions in non-production systems and update the Live systems as soon as possible. It’s also a good idea to regularly engage the services of an external penetration testing company to test security of your web application. They are well versed in the latest vulnerabilities in all the major third party frameworks, modules and components and can advise you if you are using any with known vulnerabilities.