Dynamic Application Security Testing (DAST)

Sabrina Toubbeh

University of San Diego

CSOL 560 - Secure Software Design Development

Dr. Moore

October 25, 2021

DAST
1
Abstract

Dynamic Application Security Testing (DAST) is a powerful tool that can be used to analyze an

application to find security vulnerabilities that make an organization’s application susceptible to

attack. Unlike SAST, DAST scans an application while it is running. Additionally, DAST is

effective in discovering external issues and vulnerabilities. DAST tools automatically simulate

malicious external attacks to identify critical vulnerabilities of an application. The goal of this

report is to demonstrate how a DAST tool can effectively identify vulnerabilities by risk and

categorize them into different types of issues. An analysis of the issues found helps find the root

causes and mitigation strategies. ZAP’s DAST tool and WebGoat’s intentionally vulnerable web

application were used to construct this report.

DAST
2
Table of Contents

WebGoat Dynamic Application Security Testing (DAST) 3

Summarized Findings 3

Analysis Report 5

Mitigations and Recommendations 15

References: 19
DAST
3

WebGoat Dynamic Application Security Testing (DAST)

“WebGoat is a deliberately insecure application that allows interested developers just like you to

test vulnerabilities commonly found in Java-based applications that use common and popular

open source components” (OWASP). The purpose of using a Dynamic Application Security

Testing tool is to communicate with WebGoat while it is running in order to discover potential

vulnerabilities in the application. DAST is a type of black-box security testing which uses

techniques to attack an application from the outside. Based on OWASP’s Benchmark Project,

DAST is extremely useful due to the fact that it has a lower false positive rate than other

application security testing tools (Peterson, 2021). DAST can also identify configuration issues

missed by other AST tools.

Summarized Findings

Using the ZAP tool, a scan was performed on the WebGoat application. ZAP found potential

vulnerabilities in WebGoat based on known attacks. The table below shows the security issues

based on their impact (potential damage).

Table 1: Summary of Alerts

Risk Level Number of Alerts

High 1

Medium 2

Low 3
DAST
4

Informational 5

Table 2: Alerts

Name Risk Level Number of Instances

SQL Injection High 1

Parameter Tampering Medium 1

Vulnerable JS Library Medium 3

Absence of Anti-CSRF Tokens Low 4

Cookie No HttpOnly Flag Low 4

Cookie Without SameSite Attribute Low 4

Charset Mismatch (Header Versus Meta Content-Type Informational 1

Charset)

Information Disclosure - Suspicious Comments Informational 18

Loosely Scoped Cookie Informational 5

Timestamp Disclosure - Unix Informational 9

DAST
5
Analysis Report
DAST
6
DAST
7
DAST
8
DAST
9
DAST
10
DAST
11
DAST
12
DAST
13
DAST
14
DAST
15

Mitigations and Recommendations

The table below provides a list of mitigation solutions to improve security of the application. All

the solutions come from the report that ZAP generated.

Issue Mitigation

SQL Injection Do not trust client-side input, even if there is

client-side validation in place.
In general, type check all data on the server
side.
If the application uses JDBC, use
PreparedStatement or CallableStatement, with
parameters passed by '?'
If the application uses ASP, use ADO
Command Objects with strong type checking
and parameterized queries.
If database Stored Procedures can be used,
use them.
Do *not* concatenate strings into queries in
the stored procedure, or use 'exec', 'exec
immediate', or equivalent functionality!
Do not create dynamic SQL queries using
simple string concatenation.
Escape all data received from the client.
Apply an 'allow list' of allowed characters, or
a 'deny list' of disallowed characters in user
input.
Apply the principle of least privilege by using
the least privileged database user possible.
DAST
Parameter Tampering
Vulnerable JS Library
Absence of Anti-CSRF Tokens
16
In particular, avoid using the 'sa' or 'db-owner'
database users. This does not eliminate SQL
injection, but minimizes its impact.
Grant the minimum database access that is
necessary for the application.
Identify the cause of the error and fix it. Do
not trust client side input and enforce a tight
check on the server side. Besides, catch the
exception properly. Use a generic 500 error
page for internal server error.
Upgrade to the latest version of
jquery-ui-dialog (Beagle, 2021)
● As part of patch management,
implement version management for
JavaScript libraries.
● Remove libraries that are no longer in
use to reduce your attack surface.
Phase: Architecture and Design
Use a vetted library or framework that does
not allow this weakness to occur or provides
constructs that make this weakness easier to
avoid.
For example, use anti-CSRF packages such as
the OWASP CSRFGuard.
Phase: Implementation
Ensure that your application is free of
cross-site scripting issues, because most
CSRF defenses can be bypassed using
attacker-controlled script.
Phase: Architecture and Design
Generate a unique nonce for each form, place
the nonce into the form, and verify the nonce
upon receipt of the form. Be sure that the
nonce is not predictable (CWE-330).
Note that this can be bypassed using XSS.
DAST
17

Identify especially dangerous operations.

When the user performs a dangerous
operation, send a separate confirmation
request to ensure that the user intended to
perform that operation.
Note that this can be bypassed using XSS.
Use the ESAPI Session Management control.
This control includes a component for CSRF.
Do not use the GET method for any request
that triggers a state change.
Phase: Implementation
Check the HTTP Referer header to see if the
request originated from an expected page.
This could break legitimate functionality,
because users or proxies may have disabled
sending the Referer for privacy reasons.

Cookie No HttpOnly Flag Ensure that the HTTPOnly flag is set for all
cookies

Cookie Without SameSite Attribute Ensure that the SameSite attribute is set to
either 'lax' or ideally 'strict' for all cookies

Charset Mismatch Header Versus Meta Force UTF-8 for all text content in both the
Content-Type Charset HTTP header and meta tags in HTML or
encoding declarations in XML.

Information Disclosure- Suspicious Remove all comments that return information

Comments that may help an attacker and fix any
underlying problems they refer to.

Loosely Scoped Cookie Always scope cookies to a FQDN (Fully

Qualified Domain Name).
DAST
18

Timestamp Disclosure-Unix Manually confirm that the timestamp data is

not sensitive, and that the data cannot be
aggregated to disclose exploitable patterns.
DAST
19
References:

“Owasp WebGoat.” OWASP WebGoat - Learn the Hack - Stop the Attack,

https://owasp.org/www-project-webgoat/.

Peterson, J. (2021, April 30). Dynamic Application Security Testing: Dast Basics. WhiteSource.

Retrieved October 26, 2021, from

https://www.whitesourcesoftware.com/resources/blog/dast-dynamic-application-security-testing/.

Vulnerable Javascript Library . Vulnerable javascript library. (2021, June 8). Retrieved October

26, 2021, from https://beaglesecurity.com/blog/vulnerability/vulnerable-javascript-library.html.

ZAP. (n.d.). Active Scan.

https://www.zaproxy.org/docs/desktop/start/features/ascan/