LECTURE 6 –

DYNAMIC APPLICATION
SECURITY TESTING (DAST)

1502371 - SECURE SOFTWARE DESIGN AND

DEVELOPMENT

FALL 2025-26

M5 - 220 srubab@[Link]
Dr. Saddaf Rubab
 Introduction
• A quick recap to SAST and DAST

Penetration testing
• What is PenetrationTesting
• Open Source Security Testing Methodology
THIS LECTURE Manual (OSSTMM)
COVERS • OWASP Application Security Verification
Standard
• Pen Tools
• Limitations of Pen Tools
Other DAST
• Interactive Application Security Testing (IAST)
• Runtime Application Self-Protection (RASP)
INTRODUCTION

 In this lecture unit we’ll look at the other side of the coin for
application testing—DAST—that actively attacks a running
application.
 You need both Static Application Security Testing (SAST) and
Dynamic Application Security Testing (DAST) for a 360-degree
view of how your application is built and how it behaves.
 DAST tools are a form of penetration testing or Black Box
testing, in that testers don’t need to possess the knowledge
about the application, its design, structure, or requirements.
 On the other hand, DAST tools are possible to attack, so their
use should be well controlled and well understood.
PENETRATION (PEN) TESTING

 Penetration testing (pen testing) involves

actively attacking and analyzing the behavior of a
deployed application or network devices.
 The intent of a penetration test is to
 identify potential vulnerabilities
 determine exploitability of an attack and
 the degree of business impact of a successful exploit.
PENETRATION (PEN) TESTING

 Penetration testing is performed from the

perspective of an attacker:
 External: outside attacker (one who has no
inside knowledge of the application) and
involves exploiting identified vulnerabilities
to break the system or gain access to
unauthorized information.
 Internal: simulates a threat from within
software who has some access. It is
conducted to identify vulnerabilities that
could be exploited by an insider or an
external threat who has bypassed the
perimeter defenses.
OPEN SOURCE SECURITY TESTING METHODOLOGY
MANUAL (OSSTMM)

 A useful guide to help with planning how to conduct pen testing is the Open
Source Security Testing Methodology Manual (OSSTMM) as a peer-reviewed
methodology for performing security tests and metrics.

 OSSTMM test cases are divided into five channels (sections):

1. Human Security: Security of human interaction and communication is tested operationally

2. Physical Security: as any tangible/physical element of security that takes physical effort to operate
3. Wireless Communications: Electronic communications, signals, and emanations are all considered wireless
communications as a part of operational security testing.
4. Telecommunications: Whether the telecommunication network is digital or analog, any communication
conducted over telephone or network lines
5. Data Networks: includes electronic systems and data networks that are used for communication or
interaction via cable and wired network lines
OPEN SOURCE SECURITY TESTING METHODOLOGY
MANUAL (OSSTMM)

 Therefore, these sections collectively test:

 Information and data controls
 Personnel security awareness levels
 Fraud and social engineering control levels
 Computer and telecommunications networks
 Wireless devices, mobile devices
 Physical security access controls, security processes, and physical locations such as buildings,
perimeters, and military bases
OWASP’S ASVS
 Another important guide for Pen Testing planning is the OWASP
Application Security Verification Standard 4.0.3 or ASVS.
 The latest edition of ASVS was released to the public in March 2021
and is available on [Link]
 This standard can be used to establish a level of confidence in the
security of Web applications only.
 It provides developers with a list of requirements for secure web
application development.
 It provides a basis for testing the web application:
 technical security controls of application
 technical security controls in the environment
OWASP’S ASVS (CONTD…)

 The Application Security Verification Standard defines three

security verification levels, with each level increasing in depth.
1. ASVS Level 1 is for low assurance levels, and is completely
penetration testable
2. ASVS Level 2 is for applications that contain sensitive data,
which requires protection and is the recommended level for most
web apps
3. ASVS Level 3 is for the most critical applications—applications
that perform high value transactions, contain sensitive medical
data, or any application that requires the highest level of trust.
PENETRATION (PEN) TESTING (CONTD…)
Security experts and skilled QA Testers perform PEN testing with the help of automated tools and/or manual
penetration testing.
 A manual penetration test involves humans actually attacking the system by sending malicious requests and
carefully inspecting every single response.
 They carry out the testing by hand, with or without the help of penetration testing software, but they do not
rely exclusively on the automated testing tool to perform all the work.
 The most significant advantage of manual penetration testing is the ability to discover business logic
vulnerabilities.
 The obvious drawback is that it is costly and time-consuming, since it requires humans with specialized skills
to perform.
 Pen testing or black box scanners can take quite a while to completely analyze a complex or large application.
Like SAST products, you don’t want people waiting around for results until they can perform their jobs.
 AUTOMATED PEN TESTING WITH BLACK BOX SCANNERS
 Similar to the automated analysis of source code (SAST), you can carry out automated black box
penetration testing.
 DAST tools need to be “skilled” how to follow the logic, information flow, and data entry, in the context of the
business use of the application.
 Testers who are making sure that the application is working properly in a business context often run and
record these tests and make sure that the test data supports the ability to test the application from start to
finish.
 To use these tools correctly, the testers and security team need to coordinate how and when the scans are set up
to run.
 Testers often use a testing suite, like Selenium, to manage the testing process and record testing steps for later
playback as the application changes or new features are added.
 The DAST tool can use the Selenium test scripts to replay the testing, but instead of entering data appropriate
for the entry field, the tool will use attack strings (like a XSS injection string) in as many different variations
of them as it’s programmed to test, then review the HTML page that’s received back from the server to
determine if the attack succeeded or not.
 AUTOMATED PEN TESTING WITH BLACK BOX SCANNERS
(CONTD…)

 Here are a few of penetration testing tools and suites:

 Vercode DAST
 AppScan Enterprise (ASE)
 Fortify WebInspect
 Appknox
PENETRATION TESTING TOOLS
 The “Swiss Army knife” of a hacker usually has several tools, from port
scanners to Web application
 Kali Linux – The Hacker's Swiss Army Knife When it comes to ethical
hacking and cybersecurity, one name always stands out
 Most all of the Open Source pen testing tools come bundled within the free
Kali Linux distribution.
 It has tools for application level attacks, network level attacks, and
everything in between.
 It is part of the standard toolbox for most professional pen testers. It’s a
handy tool for people starting on the path to hacking custom-developed
applications since everything a hacker needs are there in one place.
 Applications running in Production may be vulnerable and if those
vulnerabilities are exploited, the application may stop running or cause the
loss of real data.
LIMITATIONS AND CONSTRAINTS OF PEN TESTING
 To expand on the point earlier, automated testing on an entire system requires that the testing tool be able to
log in to the application just as an end user would to access the security-relevant parts of the program or
system.
 Example: An e-banking application provides a robust example. For any nontrivial features of the
application (e.g., paying bills, checking balances, applying for loans or credit cards), a log-in is required
so the application can properly identify the customer and only provide information related to that
customer’s accounts.
 Pen testing tools require the same access if they are being used to access the security of protected Web forms
and functions.
 Most products allow you to configure the credentials needed, but it is important that the test accounts that are
used for logging in are reflective enough of real-life data.
 As a result, it’s important that the testing environment mirror the Production environment as much as possible,
you have to assure that your QA test environment can behave nearly identically to your production
environment, without the risks of using real-life data for testing purposes.
INTERACTIVE APPLICATION SECURITY TESTING (IAST)
 An emerging technology, Interactive Application Security Testing
(IAST) tools help with identifying and managing security risks of
software vulnerabilities discovered in running Web applications using
dynamic testing (often referred to as runtime testing) techniques.
 IAST works through software instrumentation or arangement, or the use
of instruments to monitor an application as it runs and gather information
about what it does and how it performs.
 IAST tools work by instrumenting applications through agents and
sensors in running applications and continuously analyze all application
interactions initiated by manual tests, automated tests, or a combination of
both to identify vulnerabilities in real time.
 In addition, some products integrate software composition analysis (SCA)
tools to address known vulnerabilities in open source components and
frameworks.
 INTERACTIVE APPLICATION SECURITY TESTING (IAST)
(CONTD…)
 IAST automatically identifies and diagnoses software vulnerabilities in applications and Application
Programming Interfaces (APIs).
 IAST is not a scanner. It continuously monitors your applications for vulnerabilities from within.
 IAST runs throughout your development lifecycle and instantly alerts you through the tools you’re already
using in development and test.
 The key distinguishing feature of IAST is that it uses instrumentation to gather security information and
telemetry directly from running code
 Some of the popular IAST tools are available from:
 Contrast Security Assess
 WhiteHat Security IAST
 Checkmarx IAST
RUNTIME APPLICATION SELF-PROTECTION (RASP)
 RASP is a technology that runs on a server and kicks in when an application runs.
 It’s designed to detect attacks on an application in real time.
 When an application begins to run, RASP can protect it from malicious input or behavior by analyzing both the
app’s behavior and the context of that behavior.
 It helps to continuously monitor app’s behavior, attacks can be identified and mitigated immediately without
human intervention.
 RUNTIME APPLICATION SELF-PROTECTION (RASP)
(CONTD…)
 RASP builds security into a running application wherever it resides on a server, usually through agents.
 It intercepts all calls from the application to a system, making sure they’re secure, and validates data requests
directly inside the application.
 Both Web and non-Web apps may be protected by RASP.

 The technology doesn’t affect the design of the application because RASP’s detection and protection features
run independently on the server the application hosts.
 Some of the popular RASP technologies include:
 Signal Sciences RASP
 Contrast Protect
 Fortify Application Defender
 Imperva RASP
 HOW TO CHOOSE BETWEEN SAST VS IAST VS DAST VS
RASP
 Choosing may depend on where you are in the development lifecycle and the kinds of vulnerabilities you may
be most concerned about.
 It is preferred to use a combination of each as you develop and test an application.
 For instance, as you build out code, you may use SAST. But once the first iteration is complete, you can
use RASP to check for issues.

DAST - use dynamic code analysis to spot SAST - find vulnerabilities as code is
runtime problems — weaknesses that being produced. Without SAST, a
cannot be seen when a program is not development team will likely not catch
problems until later in the software
running. DAST examines how an
development lifecycle (SDLC). SAST
application actually responds to an can identify coding errors, making it
attack, providing valuable information simple for developers to identify and
about the likelihood of a vulnerability address vulnerabilities.
being exploited.
HOW TO CHOOSE BETWEEN SAST VS IAST VS DAST VS
RASP (CONTD…)

DAST - use dynamic code analysis to spot SAST - find vulnerabilities as code is
runtime problems — weaknesses that being produced. Without SAST, a
cannot be seen when a program is not development team will likely not catch
problems until later in the software
running. DAST also examines how an
development lifecycle (SDLC). SAST
application actually responds to an can identify coding errors, making it
attack, providing valuable information simple for developers to identify and
about the likelihood of a vulnerability address vulnerabilities.
- supports continuous testing,
IAST exploited.
being RASP - operates on a server while an
monitoring, evaluation, and validation in application is running. It examines an
real time to verify whether a vulnerability application's behavior to spot attacks
and quickly address them. To do this,
is exploitable by an attacker. It provides
the RASP utility assumes control of an
critical threat alerts and reduce false application when a security incident
positives. It enable developers to address happens and tries to resolve the
security flaws in their code by identifying problem.
risky lines of code and helping to
remediate them.
DAST VULNERABILITIES

 DAST product looks for and reports on the following vulnerabilities:

 Improper input validation
 Command injection and buffer overflow attacks
 SQL injection attacks
 Cross-site scripting vulnerabilities
 Cross-site request forgeries
 Directory traversal attacks
 Broken session management
 Broken or defective authorization and access control mechanisms
REFERENCES

Software Engineering, various

sources are used