Dynamic Application Security Testing (DAST) tools are tools used to identify vulnerabilities in running applications. They operate by examining an application’s runtime inputs and outputs; testing the application’s performance by sending it a range of inputs, including malicious input, SQL injection attacks, and cross-site scripting attacks. By doing so, they can identify vulnerabilities that may not be apparent during static analysis or code reviews.
The importance of DAST tools in the DevSecOps pipeline cannot be overstated. Software is being released at an increasingly rapid rate in the current, fast-paced development environment. This means that security testing must be incorporated into the development process to guarantee that flaws are detected and corrected as soon as possible. As they may offer immediate feedback on an application’s security posture, DAST tools are a crucial part of this approach.
This article will walk you through:
- An in-depth understanding of DAST tools and how to choose the right one for your security operations.
- Running an automated full scan on a deployed application to check for vulnerabilities, using Semaphore pipelines.
Understanding Dynamic Application Security Testing
DAST testing involves analyzing an application for vulnerabilities while it is running. In other words, DAST tools test the security of an application in real-time, by simulating attacks and analyzing the application’s response. DAST tools can also be used to scan APIs, mobile applications, and web services.
Key features of DAST tools include:
- Automation: DAST tools are highly automated, allowing for quick and efficient scanning of applications. This makes them ideal for use in continuous integration and continuous delivery (CI/CD) pipelines.
- Comprehensive reporting: DAST tools generate comprehensive reports that provide detailed information about any vulnerabilities found in an application. These reports typically include information about the severity of the vulnerability, the location of the vulnerability, and recommended remediation steps.
- Integration with other tools: DAST tools can be integrated with other security tools, such as Static Application Security Testing (SAST) tools and web application firewalls (WAFs), to provide more comprehensive security.
Compared to other security testing tools, such as SAST and manual testing, DAST tools have several advantages. One of the main advantages of DAST is that they can detect vulnerabilities that might be missed by other types of testing. However, DAST is no silver bullet, so it is often recommended to use them in a combination of testing methods to ensure comprehensive application security.
Types of DAST tools
There are three main types of DAST tools: black-box, grey-box, and white-box testing tools. Each type of tool has its own unique features, advantages, and disadvantages.
- Black-box testing tools: these tools simulate an external attacker with no knowledge of the application’s internal structure. They do not have access to the source code or any other internal information about the application. Black-box testing tools rely solely on the application’s inputs and outputs to identify vulnerabilities. They are particularly useful for testing externally-facing applications such as web applications.
- Grey-box testing tools: these tools simulate an attacker with limited knowledge of the application’s internal structure. They have some access to the application’s internal workings, such as the database schema or API endpoints, but do not have access to the source code. Grey-box testing tools are handy for testing web applications and APIs.
- White-box testing tools: these tools have full access to the application’s internal structure, including the source code. They analyze the application’s code to identify potential vulnerabilities. White-box testing tools are handy for testing custom-built applications.
To sum up, black-box testing tools are useful for testing externally facing applications, grey-box testing tools are useful for testing web applications and APIs, and white-box testing tools are useful for testing custom-built applications.
Understanding the strengths and weaknesses of each type of tool can help you choose the most appropriate tool for your specific needs.
Popular DAST Tools
There are many DAST tools available, each with its own strengths and weaknesses. Here is an overview of some of the most popular DAST tools and their key features:
- OWASP ZAP: OWASP Zed Attack Proxy (ZAP) is a free and open-source DAST tool. It is widely used by security professionals and developers alike. ZAP provides a comprehensive set of features, including active and passive scanning, advanced spidering, and scriptable attacks. It also has a powerful API that allows for easy integration with other tools.
- Burp Suite: Burp Suite is a popular commercial DAST tool. It provides a comprehensive set of features for web application security testing, including automated scanning, manual testing, and advanced penetration testing. Burp Suite also has a robust API that allows for easy integration with other tools.
- Acunetix: Acunetix is a commercial DAST tool that provides comprehensive web application security testing. It includes a powerful scanner that can detect a wide range of vulnerabilities, including SQL injection and cross-site scripting (XSS). Acunetix also includes advanced reporting and integration capabilities.
- AppSpider: AppSpider is a commercial DAST tool that provides comprehensive web application security testing. It includes advanced scanning capabilities that can detect a wide range of vulnerabilities, including SQL injection and cross-site scripting (XSS). AppSpider also includes advanced reporting and integration capabilities.
When comparing DAST tools, here are some key factors to consider:
- Features: different DAST tools offer different features. Consider the specific features you need for your application security testing.
- Ease of use: some DAST tools can be complex to set up and use. Consider the ease of use of the tool when making a selection.
- Integration capabilities: DAST tools should integrate with your existing toolset. Look for tools that can easily integrate with your other security tools.
- Reporting capabilities: DAST tools should provide clear and actionable reports. Look for tools that provide detailed vulnerability information and recommendations for remediation.
- Cost: commercial DAST tools can be expensive. Consider the cost of the tool when making a selection.
In this article we will be using OWASP ZAP and integrating it into our Semaphore pipeline.
Hands-on: integration of DAST tools into a DevSecOps pipeline
To get started with this, you need to log in to your Semaphore account and create a new pipeline. If this is your first time using Semaphore, check out the getting started tutorial.
Choose the repository you want to integrate DAST with and make sure you have given Semaphore access to your repositories, and continue to set up the workflow.
We will edit the CI/CD workflow to add Scanning jobs. The name of the job as OWASP ZAP Scan, because the commands following will install OWASP ZAP Scan and run a full scan on our deployed application.
These commands are a series of terminal commands that are used to install and configure the OWASP ZAP (Zed Attack Proxy) tool on a Linux operating system.
Here’s a breakdown of each command:
sudo apt-get install -y default-jdkThis command installs the default Java Development Kit (JDK) using the apt-get package manager. The -y flag is used to automatically answer “yes” to any prompts that may appear during the installation. You need to install the default JDK (Java Development Kit) to run the OWASP ZAP tool on your pipeline because ZAP is a Java-based application.
wget https://github.com/zaproxy/zaproxy/releases/download/v2.11.0/ZAP_2.11.0_Linux.tar.gzThis command downloads the OWASP ZAP tool from its official GitHub repository. wget is a command-line utility that is used to download files from the internet.
tar -xzf ZAP_2.11.0_Linux.tar.gzThis command extracts the contents of the downloaded tar.gz file. tar is a command-line utility that is used to create and extract archive files.
export PATH=$PATH:/home/semaphore/ZAP_2.11.0This command adds the ZAP installation directory to the system’s PATH environment variable. This ensures that the ZAP executable can be run from any directory without having to specify its full path.
zap.sh -cmd -config api.disablekey=true -config scanner.attackOnStart=true -config view.mode=attack -quickurl http://example.com -quickout /tmp/results.xml -quickprogressThis command runs ZAP inline (i.e. to exit when command line options complete) and configures it with various options, such as disabling the API key requirement (api.disablekey=true), enabling the active scanner to start immediately (scanner.attackOnStart=true), setting view mode to attack mode (view.mode=attack), and specifying a target URL (http://example.com) and output file for scan results (/tmp/results.xml).
artifact push workflow /tmp/results.xmlThis command uploads files to the workflow artifacts store.
Now, run the workflow by clicking on Looks good, Start. This will create a new branch called set-up-semaphore on your repository and push the .semaphore/semaphore.yml file to the branch, running all our jobs and commands.
To see the result of your scan, navigate to your project on Semaphore, and click on the latest workflow. Select the Artifacts tab, where you can see your results file.
When you click on results.xml, it downloads the file and now you have your generated results on your computer.
Opening the file, we can see the results of the scan, including both the risks discovered and solutions.
<?xml version="1.0"?>
<OWASPZAPReport version="2.11.0" generated="Tue, 21 Mar 2023 06:26:01">
<site name="http://example.com" host="example.com" port="80" ssl="false">
<alerts>
<alertitem>
<pluginid>10020</pluginid>
<alertRef>10020</alertRef>
<alert>X-Frame-Options Header Not Set</alert>
<name>X-Frame-Options Header Not Set</name>
<riskcode>2</riskcode>
<confidence>2</confidence>
<riskdesc>Medium (Medium)</riskdesc>
<confidencedesc>Medium</confidencedesc>
<desc><p>X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks.</p></desc>
<instances>
<instance>
<uri>http://example.com</uri>
<method>GET</method>
<param>X-Frame-Options</param>
<attack></attack>
<evidence></evidence>
</instance>
</instances>
<count>1</count>
<solution><p>Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site (if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN, otherwise if you never expect the page to be framed, you should use DENY. Alternatively consider implementing Content Security Policy's "frame-ancestors" directive. </p></solution>
<otherinfo></otherinfo>
<reference><p>https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options</p></reference>
<cweid>1021</cweid>
<wascid>15</wascid>
<sourceid>1</sourceid>
</alertitem>
<alertitem>
<pluginid>10021</pluginid>
<alertRef>10021</alertRef>
<alert>X-Content-Type-Options Header Missing</alert>
<name>X-Content-Type-Options Header Missing</name>
<riskcode>1</riskcode>
<confidence>2</confidence>
<riskdesc>Low (Medium)</riskdesc>
<confidencedesc>Medium</confidencedesc>
<desc><p>The Anti-MIME-Sniffing header X-Content-Type-Options was not set to 'nosniff'. This allows older versions of Internet Explorer and Chrome to perform MIME-sniffing on the response body, potentially causing the response body to be interpreted and displayed as a content type other than the declared content type. Current (early 2014) and legacy versions of Firefox will use the declared content type (if one is set), rather than performing MIME-sniffing.</p></desc>
<instances>
<instance>
<uri>http://example.com</uri>
<method>GET</method>
<param>X-Content-Type-Options</param>
<attack></attack>
<evidence></evidence>
</instance>
</instances>
<count>1</count>
<solution><p>Ensure that the application/web server sets the Content-Type header appropriately, and that it sets the X-Content-Type-Options header to 'nosniff' for all web pages.</p><p>If possible, ensure that the end user uses a standards-compliant and modern web browser that does not perform MIME-sniffing at all, or that can be directed by the web application/web server to not perform MIME-sniffing.</p></solution>
<otherinfo><p>This issue still applies to error type pages (401, 403, 500, etc.) as those pages are often still affected by injection issues, in which case there is still concern for browsers sniffing pages away from their actual content type.</p><p>At "High" threshold this scan rule will not alert on client or server error responses.</p></otherinfo>
<reference><p>http://msdn.microsoft.com/en-us/library/ie/gg622941%28v=vs.85%29.aspx</p><p>https://owasp.org/www-community/Security_Headers</p></reference>
<cweid>693</cweid>
<wascid>15</wascid>
<sourceid>1</sourceid>
</alertitem>
</alerts>
</site>
</OWASPZAPReport>To modify our commands further, we can go back to our connected repository on GitHub, and navigate to .semaphore/semaphore.yml.
version: v1.0
name: Initial Pipeline
agent:
machine:
type: e1-standard-2
os_image: ubuntu2004
blocks:
- name: Scan Block
task:
jobs:
- name: OWASP ZAP Scan
commands:
- sudo apt-get install -y default-jdk
- 'wget https://github.com/zaproxy/zaproxy/releases/download/v2.11.0/ZAP_2.11.0_Linux.tar.gz'
- tar -xzf ZAP_2.11.0_Linux.tar.gz
- 'export PATH=$PATH:/home/semaphore/ZAP_2.11.0'
- 'zap.sh -cmd -config api.disablekey=true -config scanner.attackOnStart=true -config view.mode=attack -quickurl http://example.com -quickout /tmp/results.xml -quickprogress'
- artifact push workflow /tmp/results.xmlAfter adding new commands, commit with a message, and push to GitHub. The pipeline automatically gets triggered and runs with all the commands, including the newly added ones.
Best practices for using DAST tools
It is essential to use DAST tools effectively and prioritize vulnerabilities to get the most out of them. Here are some best practices for using DAST tools:
- Understand the application and its architecture: before starting any DAST testing, it’s essential to understand the application and its architecture. This includes understanding the input and output of the application, as well as any third-party components that it relies on. This understanding will help you configure your DAST tool more effectively.
- Use DAST tools in conjunction with other security testing tools: DAST tools are just one type of security testing tool. To get the most comprehensive understanding of an application’s security posture, it’s important to use DAST tools in conjunction with other tools such as SAST (Static Application Security Testing), manual testing, and vulnerability scanners.
- Prioritize vulnerabilities: once you’ve identified vulnerabilities using DAST tools, it’s important to prioritize them based on their severity and the potential impact on the application. Prioritization will help ensure that you’re addressing the most critical vulnerabilities first.
- Configure DAST tools effectively: DAST tools are highly configurable, and it’s important to configure them effectively to get the best results. This includes specifying the scope of testing, customizing the types of inputs that the tool sends to the application, and setting thresholds for vulnerabilities.
- Conduct regular testing: DAST testing should be conducted regularly, ideally after every new release or significant change to the application. Regular testing will help ensure that any new vulnerabilities are identified and addressed quickly.
By following these best practices, you can ensure that your DAST testing is effective and helps to improve your application’s security posture.
Conclusion
In this article, we’ve seen how DAST tools are an essential component of the DevSecOps pipeline for identifying security vulnerabilities in running applications, helping to ensure that applications are secure and free from vulnerabilities that could be exploited by attackers.
We’ve also been able to integrate OWASP ZAP, a DAST tool, into our Semaphore pipeline. By following best practices and selecting the right tool for your organization, you can ensure that your applications are secure and protected from potential threats. Now, you should take action and implement DAST tools in your pipelines to minimize the risk of security breaches and safeguard your applications.
