Why Should You Use Netsparker Web Application Security Scanner to Scan Your Website?


    In business terms, it is sometimes difficult to define what is the value of that which protects you. You can easily define tangible or economic loss that has happened — their values are easily calculable — but a lack of loss or fiscal impact is harder to define. It is easy to see why many companies may challenge the need for a web application security scanner: the value it provides may not be so easy to define, only in estimations of probable loss it prevents.

Spending money on intrusion detection systems, firewall appliances, and so forth do see up-front value: they are active preventative measures, and the data they protect is immediate visible and tangible. But a scanner is more passive, looking for things before they happen. The argument against can often boil down to this: if this is merely preventative searching, then surely intelligent developers could theoretically be trained to look for the vulnerabilities themselves.

This is possible, sure, but extremely risky and a bad approach.

Since the 1970s, the exponential complexity of software has been a well-known and studied science. Thomas J. McCabe wrote the Cyclomatic Complexity measurement in 1976, and Maurice H. Halstead wrote the Halstead Complexity Measures a year later, both of which were designed to provide quantitative and mathematical representations of how complex computer software is based on elements of the program’s code or function. But that was in the late 1970s when code was slowly entered into multi-million dollar computers the size of large meeting rooms via punch cards.

Today, infinitely more complex software can run on micro-instances of servers, and can be updated via a simple push. If code in the 1970s was at a complexity that was difficult to measure, code today is at a complexity that is perhaps simply incalculable. Furthermore, software today relies on a nearly infinite number of dependencies — OpenSSL, the Linux kernel, software libraries, database systems, the list goes on and on — all of which may be somehow insecure. Maybe the web application itself is perfectly secure, but is everything it depends upon also equally secure? How does a development team even account for all these interoperable possibilities, and then test for them every single time they deploy their code? It would simply grind software agility to a screeching halt. This is where a web vulnerability scanner’s value truly shines, being able to effortlessly perform these tasks of potentially infinite complexity for the developer, both repetitiously and accurately.


Defining and Putting Value on a Web Vulnerability Scanner

    To truly understand the benefits of a web application security scanner, we should first understand what it is not. This is important to define because proper value can be gauged only if the scope of measurement is clear.

Web application security scanners are typically not part of the active development process, meaning it is not often used before the code is pushed, integrated, and deployed. That part still requires the specificity and granularity of integration tests, build tests, code audits, and so forth. What a web application security scanner is, however, is a system that analyzes your deployed product, in part or in whole, usually as it appears to your customers. This is not something that any of the aforementioned security entities can account for, as it is a sum-of-all-parts assessment and not granular like a unit test or firewall.

Sometimes this may go overlooked if developers or management incorrectly assume that if unit and integration tests pass, or a decent firewall or IDS are in place, a good security posture is therefore likely assured. But as mentioned earlier, there are a lot of moving parts involved, like various software libraries (such as composer or pip dependencies), intermediary applications (such as nginx), or a mixture of elements (such as interconnected microservices or cloud entities). Intrusion detection systems can only recognize known patterns like failed login attempts or changed files, but a vulnerability may also exist outside the scope of all of these other security checkpoints, and can also fall outside their visibility.

These more granular elements, such as individual functions or software classes, are also not so typically targeted by an attacker. Even when code is open source or somehow otherwise made public, it is usually unlikely that an attacker will focus on those specific functions. What an attacker sees and targets is usually the overall product, which is the same focus and perspective a web application security scanner provides. This is arguably also one of the most critical focuses to have, as it is among the first things an attacker sees and most often the first thing they target.

Most of all attacks against web applications are automated, so they focus on the broad-spectrum and brute-force approach with some targeted styles (such as looking for indicators of WordPress or PHPMyAdmin). This is largely similar to how a web application security scanner operates, so by leveraging the methods attackers use (and much more), we can get a much better grasp on the potential vulnerabilities they may find and exploit.


Figure 1: Netsparker in an active scan of a live website


Enter Netsparker Web Application Security Scanner

    Since it is well-established that a web vulnerability / security scanner does indeed hold great value for a company’s security posture, it begs the question: which is the right one? There are certainly dozens to choose from, and they all of course demonstrate some value. Most will likely find the normal common vulnerability types like SQL injections or remote file inclusions, but that should come of little surprise. What sets them apart, however, are the subtleties in what they find, how they find it, and how they clearly help the user understand the dangers. This is what makes Netsparker unique: it of course looks for things that are red-flag vulnerabilities, but it also finds, reports, and even provides possible examples of methods that could be used as an attack vector in everything from simple to very complex exploits.


Figure 2: Example of an out-of-date framework warning with a known potential vulnerability

One of the things that first struck me as interesting when scanning a live website was all the various and miscellaneous information it provided, regardless of severity or potential damage. Things like jQuery versions, software exposure (did you remember to disable expose_php or server tags?), HTML comments, and much more. Normally admins and developers may not pay much attention to these things when provisioning a server or deploying an application — and admittedly these things do not often have much of a role to play in the grand scheme of vulnerabilities — but these are good things to be aware of as a healthy reminder of the security posture a server and service hold, and as a reminder of necessary additional hardening. This is a truly clever feature, and not one I have seen to this degree previously in far more expensive scanning suites.

Another thing that really impressed me were all the additional vulnerability scanning approaches Netsparker leveraged using the Chrome engine to emulate the operational activity and function of a web browser. For example, HTML5 is still relatively new in terms of DOM library support (most HTML libraries are still based on the HTML4 model), so unsurprisingly there is still quite a number of scanners that do not yet support truly support HTML5 vulnerability detection. This is a grave problem since reportedly over 60% of all websites now use HTML5.

However, in Netsparker, that support is completely there and ready out of the box. One of the most impressive parts, though, is that Netsparker has the ability to natively understand and thoroughly process, navigate and security scan single-page applications (SPA). This is crucial because it goes beyond the typical scanner that sometimes stops at analyzing AJAX calls for cross-site scripting or injections, and ensures that things like statefulness and value changes within the SPA (such as anti-cross site request forgery nonce tokens) may not be compromised. Web applications are increasingly switching to an SPA model (think like Facebook or Gmail), so the ability to fully navigate and understand the rich depth of JavaScript involved is equally incredible as it is invaluable.


Not Just Defined, But Also Demonstrated

    Web application security scanners will hint at vulnerabilities that may exist on a web service, but this only shows the what and not the how. Understanding the true depth and scope of a vulnerability must go beyond the abstract and into realization, and that is one of the most critical aspects of Netsparker. It does not just show you that a vulnerability may exist, it also demonstrates how that vulnerability can be exploited by giving a real-world example as an effort to help the scanner user know this is not a false positive.

Pretty much every single vulnerability Netsparker can detect, it can also provide a proof-of-concept example to actively demonstrate to you that not only was a vulnerability discovered, but that there is also a Netsparker-crafted exploit to show you how it can actually be exploited. The proof-based scanning concept exists as a core of the Netsparker security scanner, and is perhaps even the biggest and most important feature that sets it apart from the rest. With proof-based scanning, this eliminates the problem of false-positives cropping up during an web application scans that then need manual verification. Of course, manual verification is always a necessary step, but rather than wasting time trying to make sure the scanner was not fooled, a security or development engineer can proceed on with the fix immediately, knowing with confidence that the discovered threat is indeed real.


Figure 3: Example cross-site scripting vulnerability with proof-of-concept and confirmation

In the screenshot above, we see a lot of information for a single web application vulnerability. The OWASP and PCI classification mentioned previously are visible on the right side (along with many other classifications that may be relevant), as well as a marker as to whether Netsparker was able to confirm this as a legitimate and successfully exploitable vulnerability. In the middle we see a detailed breakdown about the vulnerability and, most importantly, the method by which Netsparker verified this vulnerability. This is simply amazing because it immediately demonstrates the value of Netsparker by saving the security engineer or developer time and giving them everything they need right there on one page. It should also be mentioned that this vulnerability was found against a single-page application, yet another example of the power Netsparker has.


Plentiful Features Leave You Not Wanting For More

    There is a very wide assortment of additional features that Netsparker web application security scanner has. One I particularly enjoyed was the web service scanning feature, specifically when against a REST API endpoint. This was actually part of the single-page application I mentioned earlier that Netsparker discovered and correctly traversed, where it also automatically discovered the REST endpoint my AJAX calls were using and tested that, too. I did not have a Swagger definition to import (which Netsparker does support!), but that was fine. Netsparker still successfully discovered, understood, and tested against the REST endpoint regardless. The artificial intelligence, if you will, that was in play here were equal parts impressive and time-saving.

Earlier in this review, I had mentioned that web application security scanners cannot replace the active development cycle itself — things where unit and integration tests typically reside. This is indeed true, however Netsparker can still fit into this model. There exists the ability to auto-generate tickets in a JIRA system, or directly to Github (which I would suspect can also be done against a self-hosted enterprise Github installation). Netsparker can also be triggered by Jenkins once your integration tests are complete and your application is being deployed to scan specific parts of your deployed application to ensure, at every deployment, that nothing has been introduced that creates a vulnerability. Even though Netsparker does not replace unit tests and other similar source code evaluations, it can still fit within the software development and deployment model with relative ease, thus saving even more time and reducing security effort by enabling the developers to participate more in the hardening and auditing of their application.

Various authentication scans against WWW-Authenticate basic and digest, and SPA JavaScript forms also proved to be quite thorough. One thing of particular interest I could see when capturing the username/password information Netsparker was sending was malformed and manipulated UTF-8 content, seemingly an attempt to break or escape data sanitization and the authentication system itself. For example, if UTF-8 is not supported in the authentication database being used — such as if your authentication table is in MySQL, using the MyISAM engine and an ASCII character set — this can help to identify potential data exposure from an uncaught MySQL exception.


Support When You Need It

    As a full disclosure, I have been working with the Netsparker organization for several years as a security articles author, so I can safely say that working with those involved in the company has been the utmost pleasure. They are quick to respond, happy to help, and truly welcoming and highly intelligent people. That is the kind of satisfaction that you can expect from the support that comes with the Netsparker product line: a team of technical people ready to help you with any problems you might encounter, after all finding vulnerabilities in web applications is not exactly the easiest of tasks.

This is not just my opinion, either. Many prominent customers including ING, Oakland University, and OpenCart have also expressed deep satisfaction with the Netsparker product line and the support they provide. Even industry experts such as Troy Hunt recommend Netsparker.

Satisfaction can of course also be found in many far more expensive web security scanners provided by Fortune 500 companies, certainly, but I personally have always enjoyed working with smaller companies because they put far more focus on the product and customers than they do on the bottom line.


Pain Points

    Nothing in this world is perfect, and it would be a disservice to withhold the pain points I experienced with Netsparker. First, being a Linux user myself, I was a little disappointed that a Linux version of Netsparker does not exist. However, as was explained to me when discussing this topic with a member of the Netsparker team, this is for good reason. Linux has an extremely wide diversity with various user interfaces (Gnome, Cinnamon, KDE, etc.) and various distribution types (RHEL, Debian, Arch, etc.). Building Netsparker with equal compatibility and stability as it has in Windows would be a remarkable task, and as a contributor to Linux and BSD projects, I can certainly understand and agree. Plus, Windows does indeed still hold a far larger market share in the enterprise desktop environment than Linux, so it of course makes sense to provide more focus there than in niche markets, at least for now.

The only other problem I experienced I would not really classify this as a bad thing, but Netsparker out-of-the-box and with no tuning is almost too thorough. Because it looks at literally every single detail available and inspects from multiple angles, a full-breadth, complete website scan can take a long time. In fact, one of the live websites I scanned initially took almost three days to complete, due to the massive variety of links it has (Netsparker exhausted every page’s option, including page sort query strings). This is, however, easily tunable by defining the depth you want to scan, things that may be repetitious elsewhere, paths to focus on or exclude, and so on. One of the tuning options I employed was the custom rewrite rules, which allowed me to specify my web application routing definitions to Netsparker, such as /user/[name] or /blog/[category]/[id], greatly reducing the time the scan takes and helping Netsparker better understand where potential injection points may exist.

You can also increase the level of concurrent connections to test with, which is additionally useful for demonstrating a possible denial-of-service attack. Most security scanners I have worked with do not take so long for a full website scan out-of-the-box, but I believe that may also have something to do with them not being nearly as thorough as Netsparker. This may have been an ever-so-slight pain point, but it is also very much a great problem to have. I would rather have too much information and depth than too little.



     A strong and sturdy security posture requires many layers and many components. Code needs to be developed securely, which requires proper software testing and auditing. Servers need to be hardened and secured, which requires skillful configuration, firewalls, intrusion detection, and more. But the overall product of a web application needs to be tested with a similar approach that most attackers take, by scanning the website for vulnerabilities, and further by assisting the security and development team in understanding where problems exist.

This is where Netsparker shows the most bang for the buck, costing perhaps far less than even the AWS stack it may be hosted on. As a security engineer, I cannot recommend this product enough as the cost is affordable, the usefulness is enormous, and the value is immeasurable. Plus, who can truly put a value on how much you save by preventing an exploit from happening? As I said in the beginning, it is sometimes difficult to define is the value of that which protects you. But with Netsparker, that value is priceless.


Additional Info

Source: CyberPunk @ February 28, 2017 at 10:15AM