Known Vulnerabilites

 

Next, at #9 on the list, we have the use of components with known vulnerabilities. While this might sound easy to avoid but tight time constraints might cause developers to use whatever libraries are available to get the job done on time. This can often lead to dependencies on libraries with security holes. OWASP states that you are likely vulnerable if you do not know the versions of all the components you use (yes, even the nested ones), if you use software that is out of date, do not scan for vulnerabilities regularly (typically this means weekly, not monthly), developers do not test the compatibility of upgraded or patched libraries, and if they do not secure the components configurations (2017).

Multiple Library Dependencies

When creating an application, you will often find yourself depending on various libraries to help speed the development process up. As the application grows it becomes easier and easier to forget what versions of libraries you are dependent on. It is important that you keep track of all dependencies and make sure that you know the version as well. OWASP has a free utility called Dependency-Check that is able to search your dependencies for known vulnerabilities. It is able to do this by checking if there is a Common Platform Enumeration identifier for any of the dependencies found. It is by no means a one-stop solution but is a great step in the right direction.

Not Patching (Software or Firmware)

Keeping up to date with software and firmware dependencies is one of the best ways to harden your application against attackers. It is often speculated that anywhere from 50%-80% of all malware is avoidable through proper patching. Furthermore, web-based attacks are primarily opportunity based, so double check your patching against components with known vulnerabilities often to reduce opportunity level for attacks. The growth in web-based applications means the attackers have a lot of targets to choose from and will often prey on the weakest of them. If your application is following basic security practices, you might prove to be a hard target to crack for the average attacker.

 

Not scanning regularly

Scanners are a great way to automate the search for vulnerabilities in an application’s code. However, it should not be your sole way to check for vulnerabilities. Proper testing is very important in creating a secure application and should be paired with vulnerability scanners. As was said earlier, OWASP has a good scanner to check if any of your dependencies have public vulnerabilities. When it comes down to more broad attack vectors such as SQL injection or cross-site scripting you will need to use a different kind of scanner. Vega is a free open source scanner that also has an API written in JavaScript. Another option is Zed Attack Proxy, which is another open source scanner that is developed by OWASP. Again, you should not be relying on a single scanner to detect all of your vulnerabilities.

 

Developers not testing

As was mentioned earlier testing your application is important in making it secure. There are many different kinds of testing to choose from, however. From a security standpoint, it is important to test your applications ability to work with updated versions of dependencies. Keeping up to date software is a great way to harden an application against a large number of different attacks. While this can be a daunting task, especially with older applications it is important that you weigh the risk before sticking with your decision to not patch your software.

 

Not securing Component Configuration

When you release an application, you want to make it is shipped in the most secure manner possible. OWASP lists the best practices as “turning off all unnecessary features by default, ensuring all switches and configuration for every feature is configured initially to be the safest possible choice, Inspecting the design to see if the less safe choices could be designed in another way, not relying on optionally installed features in the base code, and not configuring anything in preparation for an optionally deployable feature” (2009). In other words, if there is an option that makes the application less secure make sure it is off by default and siloed from the base code. The most secure option is to, of course, a redesign with security in mind. Configuration is a constant process and below, you can see the four phases of security-focused configuration management that the National Institute of Standards and Technology recommends (2011).

Planning involves developing the policy and procedures you will be incorporating. The next step is to implement them into the application. Controlling Configuration Changes is maintaining these policies and procedures throughout the lifecycle of the application. Finally, with automated tools, you would monitor the application to see if it is consistent with the baselines set (Johnson, et al. 2011).

 

Conclusion: It’s Hard to Manage Everything,  Especially When You Try To Do It Alone

Although looking through your application for all dependencies and vulnerabilities can be a tedious process, it is often a necessary one. While there are many scanners that can help automate this process, you will still need someone to do a more thorough test of the code. This again brings up the question of whether or not your organization can endure the financial, reputational, and other risks of having a vulnerable application? If the answer is no it make be a good time to check out our secure DevOps programs, including both static and dynamic applications testing. If your interested in finding out how Praetorian Secure can service your organizations need you can contact us directly at (855) 519-7329 or on via our contact page.

Online Web Application Security Project. (2009, May). Configuration.

Retrieved from https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

 

Johnson, Dempsey, Ross, Gupta, Baily. (2011, August). Guide for Security-Focused Configuration Management of Information Systems.

Retrieved from https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-128.pdf