XBOW vs. DAST

Like DAST, the XBOW autonomous offensive security platform tests the security of running applications. Unlike DAST, XBOW was built from the ground up for a world where developers and cyberattackers are fueled by AI. AI-driven pentesting adds the speed, accuracy, and ease of use that offensive security solutions need to match the velocity of modern developers and cyberattackers.

The XBOW autonomous offensive security platform tests the security of running applications. Dynamic analysis scanners do as well. What’s the difference? The two diverge at many points, but most critically with speed, accuracy, and ease of use.

The past with DAST

SAST plus DAST has been the traditional AppSec testing combination for decades. SAST, or static application security testing, scans the source code of an application, not the running app, to uncover vulnerabilities. Dynamic application security testing, or DAST, on the other hand, is black box testing that automatically tests the security of a running application. Both have been plagued with speed issues and noisy results for years. And with AI dramatically ramping up both code production and attacker velocity, both are struggling to keep up and stay relevant.

The XBOW autonomous offensive security platform also automatically tests the security of running applications, like DAST, but it was built from the ground up for a world where developers and cyberattackers are fueled by AI.

XBOW vs. DAST

	DAST	XBOW
Speed	Weeks to months of cycling through huge lists of static payloads	Hours to days of targeted, adaptive attacks
Ease of use	Cumbersome authentication and safety-guardrail workarounds	Simple authentication and ability to maneuver around guardrails
Accuracy	Significant false positives, no ability to identify business logic vulnerabilities	High accuracy due to AI validators that ensure true positives, use of AI to perform IDOR and BOLA testing, and ability to combine attack vectors
Reporting	Templated, with the same summary and recommendations for every instance of a found vulnerability	Context-aware description and recommendations for each finding, including steps to reproduce
Adding SAST to DAST	Not possible	Ability to add source code for more accuracy

DAST scan speed

Speed matters. In fact, I have talked to numerous enterprise security teams who told me they’d be happy to sacrifice the quality of DAST results to get better speed. That might seem shocking, but consider that it can take weeks to dynamically test an application. Then consider a large enterprise with thousands of apps, and it starts to seem reasonable that speed would become a priority. These customers don’t have weeks to wait for test results for only a small percentage of their attack surface. They would settle for good (not great) results that could be generated quickly.

Why do these tests take so long? One reason is because they use large static payload lists. For example, they’ll take hundreds of XSS payloads with no context and just see if anything works for every parameter on every page, the “throw it at the wall and see if it sticks” approach.

Poor crawling technology also affects DAST speed. Crawling is simply hard, and a huge use of time and resources. The need for page deduplication, plus complex JS pages and single page apps only complicate crawling further.

How XBOW improves scan speed

The XBOW autonomous offensive security platform does not use static payloads. Its testing is AI-based and adaptive. XBOW sends an attack, gets a response, and then determines its next best move to exploit the application. It doesn’t just spend excessive time cycling through payloads to see if something works. Rather, it is adjusting as it goes based on server responses and figuring out the most efficient and effective attacks. The result is better results, faster.

To illustrate XBOW’s speed: We recently asked five professional pentesters to find and exploit the vulnerabilities in 104 realistic web security benchmarks. The most senior of them, with over 20 years of experience, solved 85% during 40 hours, while others scored 59% or less. XBOW also scored 85%, but in 28 minutes.

DAST ease of use challenges

DAST scanners are notoriously known for being difficult to use. Authentication/session state configuration is very complex, often involving Selenium scripts and custom tokens. SSO further complicates authentication.

In addition, safety guardrails make DAST scanning more cumbersome. As the scanner is testing, it might get logged out, abruptly ending the test. For instance, if it is testing a change password page and accidentally changes the password, it’s now logged out for good.

How XBOW improves ease of use

XBOW has simple configurations and guardrails. With only a username and password, the XBOW AI figures out where the credentials go and how the session keeps state. It further automatically:

Understands important tokens and maintains them.
Determines when it’s been logged out and how to log back in.
Identifies and avoids unsafe parameters to attack (account deletion, password changes).

DAST accuracy/noise

DAST scanners can be very noisy. There are a lot of results, and a lot of false positives. DAST is weak at vulnerability validation, and often generates low-quality, informational findings, like a server header that discloses the server version.

Finally, DAST scanners have no (or a poor) ability to identify business logic vulnerabilities like IDOR (insecure direct object reference) or broken object level authorization (BOLA). These vulnerabilities that allow things like privilege escalation and improper account access are challenging for DAST. It lacks the ability to distinguish between a guest page and an administrator page and to determine which users can access them.

How XBOW improves accuracy/noise level

XBOW is far more accurate and less noisy than traditional DAST thanks to:

Custom AI validators that ensure findings are true positives

The use of AI to perform IDOR and BOLA testing. XBOW can look at a page and determine if it contains sensitive information and if its current user role should be allowed to view it

The ability to combine attack vectors to find a vulnerability (for example, RCE using SSRF for exfiltration)

Unique XBOW capabilities beyond DAST

The XBOW platform also has unique capabilities that a DAST scanner could simply never match, including:

Context aware report data: When a DAST scanner finds a vulnerability, it generates the same summary and solution for that vulnerability type every time. If it finds Cross-Site Scripting, it will offer the identical XSS summary and recommended solution in every instance. This templated approach leaves developers to piece together the cause of the vulnerability and how to remediate it.

XBOW generates context-aware, custom information for each vulnerability. XBOW findings include the specific exploit path, application behavior, and the code context, giving developers the data they need to take remediation action quickly.

DAST Scanner Summary:

Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.

When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.

Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code.

‍
XBOW:

The catalog search page reflects the searchTerm parameter into an inline JavaScript string without proper context-aware escaping. By supplying a backslash-quote sequence, an attacker can break out of the single-quoted string assigned to a JavaScript variable and inject arbitrary script, which is executed when the page loads.

Reflected Cross-Site Scripting (XSS) occurs when untrusted user input is included in a page’s response and interpreted as executable code in the victim’s browser. In JavaScript string contexts, output encoding must escape not only quotes but also backslashes and other control characters. Failing to do so allows crafted input to terminate the string and introduce attacker-controlled JavaScript.

In this instance, visiting a crafted URL to https://ginandjuice.shop/catalog with searchTerm=';alert(1)// (URL-encoded) triggers execution of alert(1) in the victim’s browser. This enables arbitrary JavaScript execution, which can be used to perform actions as the user, exfiltrate data in the page, or pivot to broader attacks such as CSRF.

Exploit

The endpoint /catalog embeds the value of the GET parameter searchTerm into an inline script that sets a variable, for example: var searchText = '<user-input>'; document.getElementById('searchBar').value = searchText;

The server-side escaping covers single quotes but does not escape backslashes. An attacker can supply a payload beginning with a backslash followed by a single quote to neutralize the escaping and close the string, then append arbitrary JavaScript and comment out the remainder. For example, the payload ';alert(1)// (URL-encoded as %5C%27%3Balert(1)%2F%2F) results in immediate script execution when the page is rendered.

SAST + DAST: Combining static code insights with dynamic testing results is a powerful combination not found in traditional DAST scanners, but is possible with XBOW. Users can upload source code to XBOW, which will use it as further context when evaluating findings. For example, in a recent exercise, XBOW researchers uploaded an application’s source code as part of the XBOW test configuration. After one SQLi payload failed, XBOW then turned to the source code for clues for a smarter payload, which it did indeed find.

See how fast XBOW finds vulnerabilities in your system

‍

https://xbow-website-b1b.pages.dev/traces/

Ray

Kelly

Application Security Consultant

Bluesky

Github