Overview
Dynamic Application Security Testing (DAST), also known as black box testing, is a type of Application Security Testing specifically designed for Web applications and APIs. It automates the simulation of the attacks on the running application from the outside to identify the vulnerabilities.
It is black box testing because DAST tool identifies vulnerabilities without any knowledge of the application source code, internal architecture, and programming language.
How does Dynamic Application Security Testing Works?
Now see, we will see what happens in the back when we conduct Dynamic Application Security Testing.
Dynamic Application Security Testing is generally conducted in 3 phases.
1. Crawling
In this phase, the DAST tool tries to crawl the entire website and create a sitemap of the website.
First DAST tool sends the HTTP/HTTPS request to the configured URL, after receiving the response (HTML, Javascript, API specifications, etc..), DAST tool will add that URL to the sitemap and analyze the response to find the hyperlinks after identifying the hyperlinks, the DAST tool sent the request to all the identified hyperlinks and if the DAST get the successful response (2XX or 3XX status code) then add them into the sitemap, and this process is kept on going recursively until DAST tool starts getting the hyperlinks that are already present in the sitemap.
The main goal of the Crawling is to identify as much information about the Web Application like languages used (backend and frontend), API specifications, Server details, and entry points to perform the Audit/Attack.
Example of Entry Points
GET /details?productid=10
POST /login
username=test&password=test
PUT /update_contact
{‘user_id’:’10’,’username’:’test’,’contact_no’:’1111111111’}
2. Audit/Attack
In this phase, DAST tools first select the payloads (A string that is used to test the vulnerabilities) from the extensive database of payloads based on the information gathered by the DAST tools in the Crawling phase.
The payload present in the database generally causes any noticeable changes in the web application if the vulnerability is triggered by the payload.
For example, <script>alert(1)</script> is a payload to test for XSS vulnerability or ../../../../../etc/passwd is the payload to test of local file inclusion vulnerability.
After creating the list of payloads to test various vulnerabilities, the DAST tools will craft the malicious requests by binding the payloads into the HTTP request body, header, or GET/POST parameter depending on the type of payload and send the request to the web application.
After sending the malicious HTTP request, DAST tool analyzes the response of the malicious request to check any noticeable changes that indicate vulnerability is exploited by the payload.
For Example, if a request contains local file inclusion vulnerability payload (../../../../../etc/passwd) and the response contains the /etc/passwd data, then the LFI vulnerability is exploited, and the application is vulnerable to local file inclusion vulnerability.
3. Report Generation
Once the DAST scan is complete, we can analyze the vulnerabilities to check for any false positive results and mark them as false positives so that in the next scan, DAST tool will not report the same false positive results.
Pros and Cons
Pros
- No dependence on technology
- Suitable for Production (With proper Configuration)
- Not as many false positives as in Static Application Security Testing (SAST)
- Minimal resources required only web application URL and credentials
Cons
- Unable to locate the vulnerable lines of code like Static Application Security Testing (SAST)
- DAST conduct at the later stages of Software development (Testing or Pre-Production)
- Unable to identify business login security issues
- DAST is very noisy and not suitable for running in the production environment without proper configurations
Tags:
DAST
? Definition, Working, Pros, and Cons){kind=link}