Should you pay for a Web Application Security Scanner?

If you ask 10 web security specialists which is their favorite web vulnerability scanner, most probably you will get 30 different answers. Digging deeper you will also find that while some prefer to use free tools, several others prefer to rely on a commercial web vulnerability scanning solution. This web security blog post highlights the differences between free web security tools and commercial web application security scanners.

Solving the Commercial vs Non-Commercial (free) Software Dilemma

In today’s commercial world nothing is available for free, or so most of us think. Within 10 minutes of searching on the internet for a web application security scanner for web application penetration testing, I found more than 50 non-commercial web application security scanners, i.e. they are available for free. While some only scan for a specific vulnerability classes such as SQL Injection or Cross-site Scripting, some of them seem to be a fully blown security scanners.

Therefore why should I pay for a web application security scanner when there are many available for free? How can I justify the costs incurred for buying a commercial web security scanner to the management?

Both commercial and non-commercial web application security scanners have their pros and cons. In this series of blog posts, we will look at several aspects and requirements you would typically look for when owning such software.

Automation of Web Application Security Scanning

Commercial web application security scanners have built in automated crawlers and scanners. Therefore scanning a web application for vulnerabilities is a very straightforward process. Most non-commercial web application security scanners do not have an automated crawlers and scanners. Most of them require a lot of manual intervention to detect vulnerabilities in web applications. For example, most of them have to be configured as a proxy server to capture the traffic while you manually browse the web application. Afterwards, you have to manually trigger a number of security scripts to analyse the recorded session.

Although it is not guaranteed that a commercial automated web application security scanner will crawl all areas of a web application and identify all attack surfaces, automating the process is always more efficient than manually crawling a web application. What are the guarantees that a penetration tester will access all areas and inputs in a web application and have them all recorded? Also, sometimes it is almost humanly impossible to manually crawl a large web application such as a modern ERP system.

Further reading about automation: If you would like to read more about automating web application vulnerability finding, the blog post Why Web Vulnerability Testing Needs to be Automated highlights and explains the benefits of automating web application vulnerability findings.

Ease of Use and Documentation

As explained in the previous section, some of the non-commercial web application security scanners require you to go through several procedures to identify vulnerabilities in a web application. And this is just the tip of the iceberg. Some of them have several pre requisites or run in a very specific environment, so you might encounter several difficulties even when trying to install them. And then they include a myriad of options or only run in command line.

On the opposite, an out of the box installation of a commercial web application security scanner boasts an easy to use graphical user interface and can automatically crawl and scan a wide variety of web applications. All you need to do is fire up a user-friendly wizard, configure some options and you’re ready to start the scan within minutes. Even though most of the procedures are automated, commercial scanners still have a good number of options that allow you to tweak the scanner when in need. And if you do not know how to do something, you can always RTFM 🙂

Continuous Development and Advancements – Scan for the Latest Security Checks

How many times have you started a project to drop it at a later stage because you do not have time for it? The same happens with many non-commercial projects and web application security scanners. Such scanners are typically developed by very talented developers and penetration testers as a hobby, or to automate their own work. After some time they end up online and some of them become very popular, but most of which are rarely updated or discontinued. Maybe the day pizza is available for free we have no rent to pay, these projects might survive for much longer.

Commercial web application security scanners come from a very different background. They are developed and maintained by financially secure software companies and successful businesses. Large amounts of money are invested in these type of projects. Software companies can afford good developers and can also invest in their own research departments. This type of financial stability guarantees a product built using the latest cutting edge technology that can detect the latest types of web application vulnerabilities. As long as the business is profitable, the product can be maintained and will continue to improve.

In fact, while many commercial web application security scanners are updated at least once a month, unfortunately, most of the non-commercial web security scanners are not even updated once a year.

Ability to Crawl and Scan Custom Web Application

Modern web applications are developed using a wide variety of development frameworks such as PHP, .NET, ASP, ColdFusion, Ruby, Java and more. They also include several security features such as anti-CSRF mechanism and use different types of authentication mechanism. And since SEO has become vital for all types of online businesses most of them have SEO features such as search engine friendly URLs (URL Rewrite) and custom 404 error pages.

While it is impossible for any commercial and non-commercial scanner to support all of the above development frameworks and customizations, an out of the box installation of a commercial scanner supports a wide range of development platforms. For example, Invicti has anti-CSRF token support to automatically scan websites which have built-in CSRF attack protection. Some others automatically detect URL rewrite rules and adapt to the scenario, thus reporting less or no false positives*1.

From the crawling and framework support point of view, non-commercial web application security scanners work a little bit differently. While they might not have specific support for a particular web application feature or framework because many of them require manual intervention they can be used to crawl sections of the web application and detect “low hanging fruit” vulnerabilities.

Latest Web Application Vulnerabilities Checks

Most of the non-commercial web application security scanners have a lot of shortcomings; the limited time and resources block the development advancement of such projects and research of new vulnerabilities. Therefore most of the non-commercial scanners only detect a specific, or a limited number of vulnerability classes.

Commercial web application security scanners can detect a wider range of web application vulnerabilities because they have a good financial backing. Most of the security software companies developing security scanners have the budget that is invested in researching new vulnerabilities and security trend. Some also have their own testing departments where engineers constantly launch vulnerability scans against vulnerable and non-vulnerable web applications to ensure a stable vulnerability detection rate. The results of such exercises can also be used to advise web application developers of vulnerabilities in their web applications. The blog post Are Hackers a Step Ahead? An Analysis using Web Application Vulnerabilities contains statistics of vulnerabilities discovered during such tests.

Professional Software Support

Isn’t it frustrating when you encounter a problem and support is not available? I myself used to religiously rely on non-commercial software but after several pitfalls, I had to call it a day. When I encountered a problem, support was very limited, or in some cases, it simply didn’t exist. Even worse sometimes you find out that someone else already encountered the same problem as yours months ago and no one answered to his forum/comment post yet. That’s not good enough in anyone’s books.

If while performing a penetration test at a customer’s site and I encounter a problem, I would want to solve the problem at the earliest possible. I cannot, and it is not professional to ask the customer to wait until a solution is found. And what if a solution is not found? A web application security scanner is the type of software that businesses depend on. You can download a non-commercial email client and change it anytime, or live without it for a couple of days. But web application security scanners are used to secure business web applications that are constantly evolving and under attack, by penetration testers who have a strict deadline and cost a lot of money. Therefore one wouldn’t change a web security scanner overnight after just a ten minutes research.

Hence why professional support and technical documentation are a must.  I would gladly pay for support even when using non-commercial software. Support is a lifesaver when you are stuck with your back against the wall.

Integration with Development Systems and Professional Reporting

The scope of a web application security scanner is to detect vulnerabilities and not to generate reports or integrate with other systems. Granted, but when working as part of a team or with customers, reports have to be generated and scans have to be triggered automatically by other systems; typically scanners are integrated into the software development lifecycle. So even if most of us technical people don’t like it, integration and reporting are vital features that make a web application security scanner a complete security solution. The more collaboration and integration features a security scanner has, the more the chances of it being integrated into large development projects and penetration testing teams.

Businesses quickly understood the industry’s needs and grasped the opportunity to sell more copies of their scanner. Nowadays most commercial web application security scanners have their own reporter or can export scan results in XML format so they are parsed and imported in bug tracking systems. Some of them can also be integrated with web application firewalls or other types of defence system.

And this is another subject where non commercial web application security scanners fail to deliver. Again, this is not the developers’ fault, but it could be the limited resources, or lack of support from the major players with whom they have to integrate with.

Conclusion

As we have seen in this series of blog post, it is impossible and somehow unfair to compare non commercial and commercial web application security scanner. It is like going to a race track with a race car and race against a standard road car. This does not mean that non commercial web application security scanners are inferior to commercial ones, it just means that they were built for a different purpose thus cannot be compared.

Large companies with dedicated penetration testing teams, or large web application development companies want to have an easy to use web security solution that can be easily integrated in their SDLC, help their staff to quickly finish the job, generate professional reports and can be used to automate most of the recurring boring processes to reduce the headcount. Businesses do not want to invest money in training their staff on how to use a software or to hire someone solely to run a software.

On the other hand, if you are experimenting around and willing to learn more about web application security (and have the time for it), or working on small projects, most probably a non commercial web application security scanner is the right option for you.
 
*1 To know more about false positives and their impact on web application security scanning, read The Problem of False Positives in Web Application Security and How to Tackle Them.