Building better security (6): DAST

SDLC with Testing hightlighted and the word DAST

I’ve been sharing ideas on how to build security into your development process. An important step in the development process is testing.

There are many techniques used in security testing. It’s useful to understand the different approaches, and their advantages and disadvantages. Last week we looked at Static Application Security Testing (SAST). This week we look at DAST. (If you missed any of the previous articles, I’ve included all the links at the bottom.)

What is Dynamic Application Security Testing?

Dynamic Application Security Testing (DAST) is also known as “black-box testing”. DAST works from the outside in. Unlike SAST, it doesn’t look at source code or binaries. Instead, it analyzes by executing the application.

A DAST vulnerability scanner has two key components:

  1. The crawler component
    The scan starts by pointing the scanner to the home URL. The crawler component then navigates through the links to discover as many URLs as possible. If any part of the system can’t be accessed from the home page, its URL will have to be entered manually.
  2. The detection component
    The detection component executes multiple requests against each URL. It uses an extensive list of request formats that include different attack payloads. DAST tests all HTTP and HTML access points. It also emulates random actions and user behaviours. These simulated external attacks identify vulnerabilities and flaws.

DAST scans are generally carried out in a QA environment, although they can be used in production.

For DAST to be useful, security experts often need to write tests or fine-tune the tool. These experts need to understand web security principles, as well as the application they are testing.

Advantages of DAST

  • Technology independent
    Because DAST doesn’t look at source code, it is not language or platform specific. It supports both off-the-shelf and customized programming languages and frameworks. This means you can run one DAST tool on all your applications.
  • Low false positives
    Benchmark projects show that DAST has a lower false positive rate than other application security testing tools. This means that testers can focus their attention on real vulnerabilities.
  • Identifies configuration issues
    Because DAST attacks an application from the outside in, it can easily find configuration mistakes.

Disadvantages of DAST

  • Unclear vulnerability reporting:
    DAST attacks the application from the outside. It has no access to the source code, so it cannot identify the specific lines of code when vulnerabilities are found.
  • Limited security risk coverage:
    Some risks are impossible to identify from the outside, such as insecure deserialization. According to benchmarks, even the best DASTs will only find about 18% of the existing security vulnerabilities of an application. Also remember that an attacker often has internal knowledge about the application.
  • Slow scans:
    DAST scanners are slow. A thorough DAST can take several days to finish. This does not work well for teams that deliver code frequently. And once the team has corrected any vulnerabilities, the process must be repeated again.
  • Late-stage detection:
    DAST typically happens late in the SDLC, because it needs a working application. That means the development team has already invested hours of coding, so the cost of fixing vulnerabilities is high.
  • Not highly scalable:
    DAST relies heavily on security experts to write effective tests. This makes it very difficult to scale.

Find a DAST tool

DAST tools are also known as web application vulnerability scanners. OWASP has a list of Vulnerability Scanning Tools.

You can also have a look at the Web Application Vulnerability Scanner Evaluation Project (WAVSEP) for an evaluation of some of the DAST tools.

Conclusion

Like SAST, DAST is another tool to use in your development process. Next week we’ll have a look at IAST.

Have you had any experience using DAST? Please share your views and comments. If you haven’t already, join our Security Spotlight series. You’ll get a weekly email about web application security.

And if you missed any of the previous emails, you can find them as articles on our blog:

Leave a Comment

Your email address will not be published. Required fields are marked *