The different approaches to web application security testing

When it comes to web application security, monitoring and protection in production is extremely important. However, a subset of production issues can be eliminated prior to ever reaching production with good application security testing. Therefore, having a good approach to application security testing will help you down the line. However, with many different types of tools out there, it can be hard to tell what is necessary and what works together.

Whether you are a seasoned IT professional or a new developer, you are surely aware of application testing as part of the development life cycle. Making sure the application works technically as it should, and also as the user expects it to, in terms of features is an unavoidable milestone. However, a lot of teams overlook the security testing part of this process. For a new web application, a version upgrade, or a change in the environment, it is of the utmost importance to review the vulnerabilities of your application and the potential attack vectors.

In its testing guide, OWASP recommends that “an effective testing program should have components that test:

  • People – to ensure that there is adequate education and awareness;
  • Process – to ensure that there are adequate policies and standards and that people know how to follow these policies;
  • Technology – to ensure that the process has been effective in its implementation.”

What are the primary security testing techniques?

There are multiple testing techniques that you can consider when designing a testing strategy:

Manual inspections & reviews

These are human reviews aimed at testing the security implications of people, policies, and processes through the analysis of the documentation, the security requirements, and the technology decisions, such as the coding policies and architectural designs. Furthermore, interviewing your designers and system owners can quickly help determine any security concerns and assess whether people understand security processes and policies. The trust-but-verify model should be adopted for this technique to be effective. While it can be time-consuming and relies on the availability of documentation and a skilled tester, this technique is one of the few ways to assess the adequacy of the security policies, processes, and skill sets you have in place in your organization.

Threat modeling

Thread modeling helps developers assess the risks for an application, gain a practical attacker’s view of the system, and plan mitigation strategies to face potential vulnerabilities in order to focus the available resources and attention on the main priorities. OWASP recommends that teams develop and document a threat model for all applications, as early as possible in the SDLC, as well as revise it as the application evolves. OWASP also outlines the approach to develop a threat model based on the National Institute of Standards and Technology standard (NIST 800-30) for risk assessment: 1) Decomposing the application 2) Defining and classifying the assets 3) Exploring potential vulnerabilities 4) Exploring potential threats 5) Creating mitigation strategies.

Code review

This is a white-box testing technique, which requires access to the underlying code. The source code should be made available for security testing purposes, especially when you’re developing the application in-house. Most security experts will agree that there is no way around looking at the code to accurately understand what is happening, or supposed to be happening, and to detect many significant security problems, such as flawed business logic, weak cryptography, backdoors etc. which can be extremely difficult to discover with black-box testing techniques like penetration testing. Source code review requires highly skilled security developers. Many organizations have started to use SAST (Static Application Security Testing) tools or security linting, which help detect security vulnerabilities in source code by inspecting dependencies and configuration, and ensuring that coding guidelines and standards were respected without actually executing the underlying code. These efforts can act as a check in the development process, but aren’t sufficient as an end-to-end security effort due to lack of coverage and a tendency to produce false positives.

Penetration testing

Penetration testing (or pentesting) is about testing a running application remotely, as a hacker would, to detect security vulnerabilities and assess if, and to what degree, the application can be tricked by malicious content and behaviors. Pentesting has proven to be very effective for network security but has limitations when it comes to web application security. One of pentesting’s limitations is that it occurs too late in the software development life cycle. However, it can be used to test if some specific vulnerabilities uncovered by previous reviews have been fixed. Check the Pentest Best Practices checklist to help you prepare and run an effective pentest. From the same “black-box security testing” family as pentesting, more effective automated tools include DAST (Dynamic Application Security Testing) which help find security vulnerabilities in a running web application prior to production deployment by feeding malicious data to identify vulnerabilities like SQL injections, for example. DAST can also help detect runtime flaws such as authentication and server configuration issues as well as problems which become visible only when a known user logs in.

These techniques can be used as stand-alone efforts or in combination with others, depending on the software development life cycle (SDLC) phase and the required test effort of your application.

Automated vs. manual tools: Which are better?

The best way to conduct a thorough web application security testing is:

  • to adopt a holistic approach to uncover management or operational vulnerabilities;
  • to include security in the software development life cycle;
  • to combine automated capabilities with human expertise in a balanced approach that uses several techniques whenever possible.

There is only so much data the human brain can process, and thus the power of analytics will come into play. In addition, scanners can help speed up uncovering some vulnerabilities, but the automated tools alone cannot identify issues due to the reality of their design choices, since they cannot understand the context in which the code is constructed. Consequently, they need to be used as part of a comprehensive testing program where human expertise is valuable to come up with complex attacks scenarios, in order to set up the appropriate code review methodology (see OWASP code review guide) and to validate the findings.

One more thing…

While testing is crucial, it only covers a subset of the vulnerabilities you’ll find in production. It’s simply impossible to find every vulnerability for every release of your application pre-production. You need monitoring and protection in addition to testing. Don’t forget to set up a monitoring and protection solution, in order to keep an eye on your environments, to register the impact of testing on your systems and applications, and to investigate the results. Additionally, a centralized logging platform enables you to make the most out of the analytics capabilities and provides a view across all themes (applications, network, users, etc.). Application Security Management platforms like Sqreen will deliver the unified monitoring and protection that will get you visibility into your security as well as detailed analytics and insights to act on.

More resources: You can also take a look at The DevOps Security Checklist and The DevSecOps Security Checklist to help you with the implementation of security-minded development teams.