Using Invicti To Comply With The OWASP Application Security Verification Standard When Developing Web Applications

What is OWASP?

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.

Standardizing Security’s More Dynamic Side

When dealing with web application security, there exists a trifecta of three main areas of entry that are most commonly exploited by hackers:

• the people that hold privileged access to the application;
• the services that support the application;
• the functions of the application itself.

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.

How Invicti Can Help in Writing More Secure Web Applications

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 Invicti 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.

Introducing Security During the Early Stages of Web Application Development

In fact, major organizations like Microsoft encourage the practice of running security analysis synchronously with development — known as a Security Development Lifecycle. Invicti Enterprise even has an API system that could be triggered from continuous 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.

Introduction to OWASP ASVS

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 Invicti provides opportunity to reach all the way to the extended areas of advanced classification, too. This is because of Invicti’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 “verify all authentication controls fail securely to ensure attackers cannot log in” in order to meet at least level 1 “Opportunistic” certification. Invicti 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 Invicti web security scanner, too. The V5 requirement category – “Malicious Input Handling” – is one of many categories where Invicti can particularly excel. V5.10, for example, requires developers “verify that the runtime environment is not susceptible to SQL Injection, or that security controls prevent SQL Injection” – an area Invicti checks thoroughly. In fact, Invicti is capable of identifying hundreds of vulnerability types, far exceeding the number of vulnerabilities to secure against to meet ASVS level 3 certification.

Utilize Tools to Comply with OWASP ASVS

A web scanner need not be limited to only finding after-the-fact vulnerabilities. Properly utilized, Invicti 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.