In December 2001, the Open Web Application Security Project (OWASP) was established as an international not-for-profit organization aimed at web security discussions and enhancements. For practically their entire existence, OWASP has kept track of perhaps every type of hack that could be done. Everything from social engineering, poor authentication systems cross-site scripting, DOM XSS, SQL injection, general software vulnerabilities, and more. Basically OWASP kept track and encouraged the web community to continually secure everything as best as possible.
OWASP’s mission has always been to encourage the best security practices by not only highlighting the most exploited and critical vulnerabilities but also acting as leadership in the security community to ensure education and understanding reach as many administrators as possible. Since 1999, the Common Vulnerabilities and Exposures (CVE) dictionary has existed to keep track of and alerts consumers and developers alike of known software vulnerabilities.
OWASP has kept itself mostly focused on keeping record of the most common CVEs during its tenure, and usually its suggestions focused on understanding the vulnerabilities by general categorization. Now, after an initial attempt in 2009 and reviewing industry feedback, OWASP is focusing on a strictly defined standardization to help prevent CVEs in the first place.
When dealing with web application security, there exists a trifecta of three main areas of entry that are most commonly exploited by hackers:
Privileged access is valued the most, especially when going for high-value targets and not just trying to blindly run a few scripts against a website. There exists a critical amount of social engineering in all of the biggest hacks in the past few years. In fact, even the most prestigious security researchers themselves are not immune from such techniques.
Kaspersky Lab, a prominent figure in the security industry famous for uncovering nation-state attacks such as Stuxnet, recently found itself the target of just such an incredibly detailed and intricate precision spear phishing attack not seen outside of clandestine cyber warfare against Iran and other nations. Services are also high-value targets, especially as of recently. The infamous HEARTBLEED and Shellshock vulnerabilities were not part of the most popular categories in OWASP top 10 list, but that did not stop them from quickly becoming among the most critical of the past decade.
The services that support a web application find themselves usually in one of two categories when it comes to attacks: a specific vulnerability exploited with precise focus, such as a 0day, or a broad vulnerability attacking a major weakness, such as a distributed denial-of-service attack. Typically, most service-based attacks fall in the latter category, but recently precision attacks have been making headlines, namely due to their widespread effect because of the ubiquity of the software being used.
However, the functions of the web application itself fall into the most commonly exploited categories year after year. For over a decade, the SQL injection vulnerability remained at the top of OWASP’s top 10 list of vulnerabilities, with over 6,500 major, widespread vulnerabilities in 15 years affecting both open- and closed-source software. The difficulty in preventing these kinds of attacks stems from the fact that the web application itself is highly dynamic, thus no easy “apply this patch” sort of fix exists. It is through the Application Security Verification Standard (ASVS) that OWASP intends to provide focus to development’s dynamic by providing strict and explicitly defined security guidelines.
Typically a web application security scanner is applied after the fact, when the development of the web application has mostly been done already. Yet development, at the time of writing the code itself, can benefit from a web scanner as well. In good coding practice, unit tests are employed in all major functional areas of software. Here, too, a scanner can be used effectively as another level of unit testing.
From the screenshot above you can already see how Netsparker can provide a thorough assessment of not only particular vulnerabilities, but how they are classified by various existing definitions and standards, such as PCI compliance and OWASP vulnerability classifications.
This is indeed a highly useful tool when investigating a web application, however it is usually applied after the application is mostly developed, as we mentioned earlier.
In fact, major organizations like Microsoft encourage the practice of running security analysis synchronously with development -- known as a Security Development Lifecycle. Netsparker Cloud even has an API system that could be triggered from continual build systems, like Atlassian Bamboo or Jenkins, to provide real-time and automated web application security audits. These assessments and classifications can be equally, if not more so useful during the development stage, as they save time, money, and potential major headaches.
The OWASP ASVS standard has various levels of classification, ranged 0 through 3, starting a cursory verification (preliminary scans, for example) all the way through advanced where the application is secured against all known and potential threats. By definition, the zeroth classification is intended by OWASP to be where scanners are utilized, but Netsparker provides opportunity to reach all the way to the extended areas of advanced classification, too. This is because of Netsparker’s in-depth heuristics, advanced scanning features including authentication and user input, and especially its incredible flexibility to be fine-tuned for specifics that are unique to each application.
In the OWASP ASVS standard, there exist various verification requirement categories, such as V2 - Authentication, V3 - Session Management, and so forth. Within these categories are specific requirements that must be met in order to satisfy various classification levels. For example, in the V2 - Authentication requirement category, V2.6 requires developers “[v]erify all authentication controls fail securely to ensure attackers cannot log in” in order to meet at least level 1 “Opportunistic” certification. Netsparker can go beyond the level 0 cursory scanning, helping to meet even level 3 “Advanced” certification by assisting a development team in testing and validating their application, in this instance by testing to validate the V2.6 requirement.
Other categories can find much benefit in the Netsparker web security scanner, too. The V5 requirement category – “Malicious Input Handling” – is one of many categories where Netsparker can particularly excel. V5.10, for example, requires developers “[v]erify that the runtime environment is not susceptible to SQL Injection, or that security controls prevent SQL Injection” – an area Netsparker checks thoroughly. In fact, Netsparker is capable of identifying over 200 kinds of vulnerabilities, far exceeding the number of vulnerabilities to secure against to meet ASVS level 3 certification.
A web scanner need not be limited to only finding after-the-fact vulnerabilities. Properly utilized, Netsparker can help a development team satisfy even the most advanced requirements of the OWASP Application Security Verification Standard, in almost every category. With a good set of tools and a clever use thereof, being ASVS certified is as simple as point and click.