portrait

Quentin Lieumont

DevSecOps engineer at Escape and passionate developer who loves to build
and break stuff.
LinkedIn | GitHub

Let's face it – vulnerabilities are often discovered when it's already too late.

That’s because many engineers still adopt a reactive security approach, addressing vulnerabilities after data breaches occur. More often than not, these breaches originate from external sources. According to Verizon's 2023 report, 83% of breaches involved external actors like lone hackers or criminal groups. The three primary ways in which attackers access an organization are stolen credentials, phishing, and exploitation of vulnerabilities.

That’s where DAST tools can step into your proactive security strategy. DAST tools act like real-world hackers. They interact with applications like someone from the outside would, helping you secure your applications before it’s being attacked by others. DAST goes beyond checking an application's internal state; it extends to testing its external environment.

But like every security tool out there, DAST tools do not come without limitations. How impactful are they, though? We’ll answer this question - and more - in this article.

We’ll challenge common perceptions of DAST, discuss real-world scenarios, and show you the best Open Source DAST tools that you can integrate into your automated secure pipelines (Hello DevSecOps!).

Why DAST complements SAST

Dynamic application security testing isn’t a new concept. In reality, there are many tools and companies that entered this space years ago.

And it’s not the only application security solution out there. In fact, most DevSecOps would agree that successful DevSecOps teams must use a full security toolset—including DAST and static application security testing (SAST)—to address code quality and security flaws throughout the SDLC.

SAST and DAST use different testing approaches:

  • SAST tests applications by reviewing their source code
  • DAST simulates real-world attack scenarios against the running application

By combining these together, the developers and security teams can have access to a wider range of the detected vulnerabilities, along with detailed remediation guidance for each (While a StackOverflow thread might be your best friend, it’s not always the most reliable and efficient).

According to Escape’s State of APIs 2023 security report, 87% of 6k+ public APIs were vulnerable due to an easily exploitable misconfiguration with severe business impact (API8:2023 OWASP Security Misconfiguration). Up to 12% had more serious vulnerabilities like injections, so combining your security solutions to protect your organization’s applications is no longer a nice-to-have, but a must.

DAST excels in identifying runtime vulnerabilities such as server configuration errors, authentication flaws, session management issues, cross-site request forgery, and other runtime flaws, which can be difficult or impossible to reproduce with SAST tools.

Real-world scenarios where DAST shines

Now that we have introduced the theory, let’s get back to reality.

Exploitable vulnerabilities can translate to substantial financial losses, reputational damage, and the exposure of highly sensitive data (not to mention additional fines that could result from non-compliance with regulations like PSI-DSS or HIPAA). Sectors such as finance and healthcare are particularly at risk in this matter. Let’s take a look at three examples of how using DAST tools could be beneficial in both cases.

Addressing session management issues

As mentioned before, DAST is great at detecting session management issues.

But how does it work? DAST will attempt to manipulate session tokens or cookies to test the application's capacity to protect session information. This helps prevent attackers from hijacking user sessions and getting access to either patient’s or private financial data.

Finding authentication and authorization flaws

Does your bank have strong authentication policies in place? Or is it still 2014 with JP Morgan and no MFA? That’s where DAST will be your best friend - it will check if the application enforces strong password policies and correctly handles account lockouts. More than that, it’ll assess whether authorization checks are in place to prevent unauthorized access to sensitive financial information.

Data encryption during transmission

Clear transmission of sensitive data often leads to a vulnerability that is surprisingly prevalent, impacting even the largest of corporations.

In healthcare, sensitive patient data (like medical records) are transmitted between the user's device and the server. If this communication is not encrypted, an attacker with the capability to intercept the traffic (eavesdrop) could potentially access and view the patient's medical information. This is especially risky when communication occurs over insecure channels, such as unencrypted HTTP connections.

💡
For example, the Escape team recently discovered that the Philips GraphQL API was processing sensitive requests over plain HTTP. Fortunately, we could alert the company through a vulnerability disclosure program.

How to be sure that sensitive data is always encrypted during transmission? In most cases, you can’t. DAST is here to help. DAST applications, when assessing data encryption during transmission, simulate potential attacks where they attempt to intercept and manipulate the data in transit.

What are the common challenges DAST users face?

The trend currently growing is "shift left."  And a lot of times people tend to overly focus on the left side of the SDLC and not enough on the right-hand side of the SDLC. And you can see it in the vendors. So the DAST tools usually tend to be very inefficient and they tend to not produce anything useful neither for the organization nor for security engineers. - Aleksandr Krasnov, principal security engineer at Meta on the Elephant in AppSec podcast

As with any security tool, DAST tools do come without limitations. And efficiency is one of them. DAST scans can take a long time to complete, especially when dealing with large and complex applications. Scanning every aspect of an application's surface can lead to extended testing periods, potentially delaying development timelines. It also makes it difficult to run scans on a regular basis.

💡
There are a few things you can do to reduce scan time. First, make sure you prioritize only critical components. Second, conduct targeted or incremental scans - scan only the parts of your application that have changed since the last scan. Both actions can help to streamline the testing process without sacrificing the depth of analysis.

False positives are another common pitfall in security scanners. They can lead to wasted time and resources investigating and remedying a non-issue. It can also create a sense of “security fatigue” - if you’re constantly seeing warnings about potential vulnerabilities, you may start to feel like your efforts to secure your applications are worthless.

💡
So, how do you deal with false positives? First and most important, make sure you’re using a high-quality DAST tool. A good DAST tool will have a low rate of false positives. Secondly, consider using additional tools to cross-verify your findings.
It's the responsibility of the security engineer to identify and prioritize what's needed. But it takes a security engineer to be somewhat of a software developer, so to speak, to get the idea of what's needed, be able to do the risk assessment, and being able to do and call out the specific actions. So it's not really about how to make DAST more efficient. It's more about how to make the engineering team succeed.  - Aleksandr Krasnov, principal security engineer at Meta on the Elephant in AppSec podcast

Lastly, DAST tools can be less actionable, contrary to SAST or SCA tools, even if they generate thousands of alerts. Your engineering team wouldn’t appreciate a generic explanation with five paragraphs from OWASP’s documentation provided by some of the existing DAST tools.

On one hand, it becomes the responsibility of a security engineer to provide contextualized information for the development team and drive them towards better practices. On the other hand, if you’re choosing a high-quality DAST tool, you’ll benefit from a detailed description of the alert and actionable code remediation snippets so the developer will know exactly where and how to fix it.

Now, let’s take a look at examples of some tools you can use. 

Top Open Source DAST Tools

There are several open-source DAST tools available to start testing your applications at runtime without committing straight away to more advanced solutions. Open-source tools usually come with strong community support, including extensive documentation, user forums, and active development. These resources can be essential for troubleshooting and staying updated with the latest security practices.

ZAP (formerly known as OWASP ZAP)

ZAP is a well known open-source DAST tool used for finding a variety of security vulnerabilities in web applications. Security professionals and developers alike widely use it for its comprehensive features and flexibility. The ZAP core project is accessible via GitHub Repo: zaproxy/zaproxy.Getting started with Zap is easy, but might require some customization along the way. You can follow the getting started documentation. It has a basic graphic user interface where you can set up your scans and view results: 

Pros and cons of ZAP: As a former OWASP project, ZAP benefits from strong community support, offering extensive documentation, a wide range of add-ons, and an active user base for troubleshooting. It can be integrated into CI/CD pipelines, allowing you to benefit from automated security testing as well.

While ZAP is a powerful tool, it can be overwhelming for newcomers to web application security. Its UI is quite outdated and may require some customization before it is comfortable to use. Automated scanning capabilities are limited compared to the paid tools and performing comprehensive scans can be resource-intensive for the application, and scans can take a long time to complete. However, given ZAP's well-established reputation in the community, there are ways to reduce scan time. For a step-by-step guide on improving ZAP's performance, you can refer to the Mozilla security blog.

In summary, ZAP is for you if:

  • You need an extensive open-source security testing tool
  • You require both automated scanners and tools for manual testing.
  • You are rather an experienced security professional.
  • Features like automated scanners, intercepting proxies, and comprehensive reporting are important to you.

SQLMap

SQLMap is a specialized open-source DAST tool that automates detecting and exploiting SQL injection flaws and taking over database servers. It has a powerful detection engine and offers a variety of features, making it a go-to tool for penetration testers and developers concerned with SQL injection security.

You can find it on GitHub here: sqlmapproject/sqlmap

The SQLMap website provides a good overview of the tool in action. If you’re a visual learner, you can check out their demos on YouTube as well.

Pros and cons of SQLMap: SQLMap stands out for its laser-focused functionality in detecting and exploiting SQL injection vulnerabilities. Its automated detection engine saves significant time and effort, making it a highly efficient tool for database security assessments. The efficiency and depth of SQLMap's analysis are unmatched in its specific area of expertise, providing users with detailed insights into potential database vulnerabilities.

However, SQLMap's specialization also comes with limitations. Its primary focus on SQL injection means it does not address a broader spectrum of web application vulnerabilities, which could require the use of additional tools for comprehensive security testing. If not used with the necessary expertise and caution, SQLMap can potentially impact the performance and stability of the targeted database. It requires a careful and knowledgeable approach to avoid unintended consequences during testing.

To recap, SQLMap is for you if:

  • You are focused on detecting and exploiting SQL injection vulnerabilities.
  • You need a tool that supports a wide range of database management systems.
  • Tasks like fingerprinting the database, extracting data, and gaining shell access are important to you.

Nikto

Nikto is a popular open-source DAST tool that performs comprehensive tests against web servers for multiple items, including dangerous files/CGIs, outdated server software, and other problems.

Its GitHub Repo can be found here: sullo/nikto

To test it, you can simply run the following inside a docker container:

$ docker run frapsoft/nikto -host https://my.server.com/

- Nikto v2.1.5
---------------------------------------------------------------------------
+ Target IP:          X.X.X.X
+ Target Hostname:    my.server.com
+ Target Port:        443
+ Start Time:         2023-11-17 11:39:53 (GMT0)
---------------------------------------------------------------------------
+ Server: No banner retrieved
+ The anti-clickjacking X-Frame-Options header is not present.
+ ...
+ End Time:           2023-11-17 11:41:05 (GMT0) (72 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Pros and cons of Nikto: Nikto is well-known for its speed and efficiency in scanning web servers. It excels in quickly identifying common vulnerabilities (like XSS and SQL injections) and server configuration issues, making it an excellent tool for rapid assessments. Nikto is regularly updated to detect the latest known vulnerabilities and server misconfigurations. It now has more than 6,700 vulnerabilities in its database and ensures that users are always equipped with up-to-date security scanning capabilities. It can also guess the subdomains of the scanned domain.

On the downside, Nikto focuses primarily on web server vulnerabilities. It does not provide a comprehensive scan of the complete web application, including the business logic or deeper application-level flaws. This narrower scope can be a limitation for users seeking a more holistic web application security assessment. Still, it can be supplemented with other tools to achieve a more comprehensive analysis.

In addition, Nikto is also not very user-friendly, lacking a graphical user interface and operating solely from the command line. You can’t know whether your scan is still being executed or completely stuck. This can be a daunting experience for security engineers less acquainted with development, especially considering some users' complaints about the lack of support or a well-developed community that exists with OWASP ZAP.

Nikto is for you if:

  • You need a straightforward and versatile web server scanner.
  • You want a tool that quickly scans web servers and provides detailed reports that can be exported as plain text, XML, HTML, and CSV format.
  • You’re already using Kali Linux

Conclusion

When it comes to website security, there are two main options: paid tools or open-source tools. So, you can ask yourself, which is better?

The most important is to understand how the tool exactly works. Would you be able to perform all the things you need for web apps as an external entity? Is it scalable and can easily be integrated into your SDLC?

Open-source DAST tools are free and usually have large community support. Paid tools tend to be more comprehensive and offer more features. A high-quality paid tool will provide almost no false positives, actionable remediation code snippets for developers, and faster scanning times.

We do believe that the future of DAST tools is customization. Each application is different and operates in a different business context. In the end, it’s the security engineer who needs to implement the most precise and custom tests based on their application needs. The next generation of DAST tools must provide them the ability to do just that.