Dynamic application security testing: Difference between revisions

Revision as of 11:51, 17 April 2023

Latest revision as of 20:31, 26 August 2025

(13 intermediate revisions by 10 users not shown)

Line 1:

{{Short description|Testing process to determine security weaknesses}}

A '''dynamic application security testing''' (DAST) is a non functional testing process where one can assess an application using certain techniques and the end result of such testing process covers security weaknesses and vulnerabilities present in an application. This testing process can be carried out either in manual way or by using automated tools. Manual assessment of an application involves a more human intervention to identify the security flaws which might slip from an automated tool. Usually business logic errors, race condition checks, and certain zero day vulnerabilities can only be identified using manual assessments. On the other side, a DAST tool is a program which communicates with a web application through the web front-end in order to identify potential security vulnerabilities in the web application and architectural weaknesses.<ref>[http://projects.webappsec.org/w/page/13246986/Web%20Application%20Security%20Scanner%20Evaluation%20Criteria Web Application Security Scanner Evaluation Criteria version 1.0], WASC, 2009</ref> It performs a [[black-box]] test. Unlike [[static application security testing]] tools, DAST tools do not have access to the source code and therefore detect [[Vulnerability (computing)|vulnerabilities]] by actually performing attacks.

'''Dynamic application security testing''' ('''DAST''') represents a [[non-functional testing]] process to identify security weaknesses and vulnerabilities in an application. This testing process can be carried out either manually or by using automated tools. Manual assessment of an application involves human intervention to identify the security flaws which might slip from an automated tool. Usually [[business logic]] errors, [[race condition]] checks, and certain [[Zero-day vulnerability|zero-day vulnerabilities]] can only be identified using manual assessments.

A '''dynamic application security testing''' (DAST) is a non functional testing process where one can assess an application using certain techniques and the end result of such testing process covers security weaknesses and vulnerabilities present in an application. This testing process can be carried out either in manual way or by using automated tools. Manual assessment of an application involves a more human intervention to identify the security flaws which might slip from an automated tool. Usually business logic errors, race condition checks, and certain zero day vulnerabilities can only be identified using manual assessments. On the other side, a DAST tool is a program which communicates with a [[web application]] through the web front-end in order to identify potential security vulnerabilities in the web application and architectural weaknesses.<ref>[http://projects.webappsec.org/w/page/13246986/Web%20Application%20Security%20Scanner%20Evaluation%20Criteria Web Application Security Scanner Evaluation Criteria version 1.0], WASC, 2009</ref> It performs a [[black-box]] test. Unlike [[static application security testing]] tools, DAST tools do not have access to the source code and therefore detect [[Vulnerability (computing)|vulnerabilities]] by actually performing attacks.

DAST tools allow sophisticated scans, detecting vulnerabilities with minimal user interactions once configured with host name, crawling parameters and authentication credentials. These tools will attempt to detect vulnerabilities in query strings, headers, fragments, verbs (GET/POST/PUT) and DOM injection.

Line 5 ⟶ 8:

==Overview==

DAST tools facilitate the automated review of a web application with the express purpose of discovering security vulnerabilities and are required to comply with various regulatory requirements. Web application scanners can look for a wide variety of vulnerabilities, such as input/output validation: (e.g. [[cross-site scripting]] and [[SQL injection]]), specific application problems and server configuration mistakes.

In a copyrighted report published in March 2012 by security vendor Cenzic, the most common application vulnerabilities in recently tested applications include:<ref>{{cite web|url=https://info.cenzic.com/Trend-Report-Application-Security.html|archive-url=https://archive.today/20121217132011/https://info.cenzic.com/Trend-Report-Application-Security.html|url-status=dead|archive-date=17 December 2012|title=2012 Trends Report: Application Security Risks|publisher=Cenzic, Inc.|date=11 March 2012|accessdate=9 July 2012}}</ref>

{| class="wikitable" style="text-align: left;"

|-

| 37% || [[Cross-site scripting]]

|-

| 16% || [[SQL injection]]

|-

| 5% || [[Path disclosure]]

|-

| 5% || [[Denial-of-service attack|Denial-of-service]]

|-

| 4% || [[Arbitrary code execution|Code execution]]

|-

| 4% || [[Memory corruption]]

|-

| 4% || [[Cross-site request forgery]]

|-

| 3% || [[Data breach|Information disclosure]]

|-

| 3% || [[File inclusion vulnerability|Arbitrary file]]

|-

| 2% || [[File inclusion vulnerability|Local file inclusion]]

|-

| 1% || [[File inclusion vulnerability|Remote file inclusion]]

|-

| 1% || [[Buffer overflow]]

|-

| 15% || Other ([[Code injection|PHP injection]], [[Code injection|Javascript injection]], etc.)

|}

==Commercial and open-source scanners==

Line 42 ⟶ 14:

Open-source scanners are often free of cost to the user.

===Strengths===

Security researcher Shay Chen has previously compiled an exhaustive list of both commercial and open-source web application security scanners.<ref>[http://sectoolmarket.com/price-and-feature-comparison-of-web-application-scanners-unified-list.html Comparison of Cloud & On-Premises Web Application Security Scanning Solutions]. SecToolMarket.com Retrieved 2017-03-17</ref> The list also highlights how each of the scanners performed during his benchmarking tests against the Web Application Vulnerability Scanner Evaluation Project (WAVSEP).

The WAVSEP platform is publicly available and can be used to evaluate the various aspects of web application scanners: technology support, performance, accuracy, coverage and result consistency.<ref>[https://github.com/sectooladdict/wavsep/wiki WAVSEP Platform] Retrieved 2017-03-17</ref>

===DAST strengths===

These tools can detect vulnerabilities of the finalized [[release candidate]] versions prior to shipping. Scanners simulate a malicious user by attacking and probing, identifying results which are not part of the expected result set, allowing for a realistic attack simulation.<ref>{{Cite web|title=SAST vs DAST|url=https://research.g2.com/insights/sast-vs-dast|url-status=live|website=G2 Research Hub|archive-url=https://web.archive.org/web/20200503220256/https://research.g2.com/insights/sast-vs-dast |archive-date=2020-05-03 }}</ref> The big advantage of these types of tools are that they can scan year-round to be constantly searching for vulnerabilities. With new vulnerabilities being discovered regularly this allows companies to find and patch vulnerabilities before they can become exploited.<ref>{{Cite web|title=The Importance of Regular Vulnerability Scanning|url=https://appcheck-ng.com/importance-of-vulnerability-scanning/|url-status=live|website=AppCheck Ltd|archive-url=https://web.archive.org/web/20200806101730/https://appcheck-ng.com/importance-of-vulnerability-scanning/ |archive-date=2020-08-06 }}</ref>

As a dynamic testing tool, web scanners are not language-dependent. A web application scanner is able to scan engine-driven web applications. Attackers use the same tools, so if the tools can find a vulnerability, so can attackers.<ref>{{Cite web |last=Bashvitz |first=Gadi |title=DAST Pros and Cons |url=https://brightsec.com/blog/dast-dynamic-application-security-testing/ |access-date=2023-03-21 |website=Bright Security}}</ref>

===DAST weaknessesWeaknesses===

While scanning with a DAST tool, data may be overwritten or malicious payloads injected into the subject site. Sites should be scanned in a production-like but non-production environment to ensure accurate results while protecting the data in the production environment.

Line 58 ⟶ 26:

The tool cannot implement all variants of attacks for a given vulnerability. So the tools generally have a predefined list of attacks and do not generate the attack payloads depending on the tested web application. Some tools are also quite limited in their understanding of the behavior of applications with dynamic content such as [[JavaScript]] and [[Adobe Flash|Flash]].

== See also ==

A report from 2012 found that the top application technologies overlooked by most Web application scanners includes [[jQuery]], [[REST]], and Google WebToolkit in [[AJAX]] applications, Flash Remoting (AMF) and [[HTML5]], as well as mobile apps and Web Services using [[JSON]] and REST. [[XML-RPC]] and SOAP technologies used in Web services, and complex workflows such as shopping cart, and [[Cross-site request forgery|XSRF/CSRF]] tokens.<ref>[http://www.securityweek.com/web-application-scanners-challenged-modern-web-technologies Web Application Scanners Challenged By Modern Web Technologies]. SecurityWeek.Com (2012-10-25). Retrieved on 2014-06-10.</ref>

<ref>[https://pentesting.company/web-application-security-testing/ Web Application Security Testing] Retrieved 2020-11-04</ref>

* [[Security testing]]

* [[Static application security testing]]

* [[Interactive application security testing]]

==References==