Applications have long evolved from monolithic structures to complex, cloud-native architectures. This means that the tried-and-true methods we rely on are becoming dangerously outdated. For AppSec to keep pace, we must look beyond current tooling and revisit the very fundamentals of DAST – the automated discipline of black box testing.

The basics of black box security testing

Before diving into modern challenges, let’s revisit the three pillars of any successful black box security test: a foundation that remains constant even as technology shifts:

1. State: The application must be put into a specific condition that exposes potential vulnerabilities.
2. Payloads: A relevant attack string must be sent to trigger the vulnerability. Payloads must be crafted to match the underlying technologies and the desired aggression (e.g., a simple SLEEP vs. a data-altering DELETE).
3. Assertions: You need a reliable way to determine if the payload was successful. This can be as simple as a script alert(1) or as complex as measuring response time changes for a Blind SQL injection.

These fundamentals are always constrained by two major resources:

• Server load: Can the system (especially a production system) handle the load of testing? Testing production is often ideal because it holds all business-critical data and is never truly equal to staging.
• Scanning time & cost: Resources are finite. A scan running in a fast build pipeline needs a different time budget than one in a QA environment. Furthermore, computational costs for rendering, traffic, and even AI tokens must be factored in.

Why the old methods are breaking

The black box fundamentals are stable, but the applications we test have been completely revolutionized.

Monolithic legacy architecture (The “good old days”)
In the traditional LAMP stack world, things were simpler:

• URL = State: Each state of the application was directly accessible via a URL.
• Visible technology: The underlying tech stack was relatively easy to determine, and the alternatives were few.
• Direct payload response: Payloads directly triggered the application you were testing, with minimal movement through system components.

Modern Application Architecture

Today, the architecture is complex and layered, breaking all the old assumptions:

• URL ≠ State: Application state is now driven by actions (like clicking a button to add a product to a cart), not just URLs. Modern URLs often use fragments (#) and may change client-side via the JavaScript history API without triggering HTTP requests.
• Hidden technology stack: Applications now consist of CDNs, cloud storage, container groups, message queues (like Kafka), and schedulers. The underlying tech is hidden and protected behind many layers.
• Payloads trigger across components: A single payload might travel through a Kafka message bus and trigger in a separate system, potentially due to serialization/deserialization differences between coding languages, or even in a third-party service (e.g., a logging tool).

With architecture fundamentally changed, it is no wonder many black box tools, often based on decades-old underlying projects, are struggling to keep up.

The (very much) required shifts in black box methodology

To meet the challenges of modern apps, black box tools must evolve their approach to state, payloads, and assertions.

1. Generating State

• Graph, not a tree: URL trees are obsolete. A modern web app must be modeled as a graph, where a node is a state and an edge is an educated guess of an action that modifies the state. This requires modeling both client-side and server-side state.
• Recreation of state: You can no longer reliably recreate a state with just a URL or a HAR archive. Tools must replay the sequence of actions taken to reach a specific state.
• Short-lived states: States are increasingly short-lived (e.g., JWTs with short TTLs), making it difficult for traditional crawlers to test them effectively later on.

2. Crafting payloads

• Context-aware payloads: Since the full stack is hidden, payloads must be designed to work in multiple contexts. A single string must survive serialization/deserialization across different programming languages as it propagates through the system and potentially triggers in a different software stack.

3. Making Assertions

• Delayed and out-of-band triggers: Payloads may now trigger much later, possibly after being queued for processing or returning from a different view. The Log4j vulnerability was a clear example of payloads triggering deep within the architecture, requiring out-of-band methods and network pingbacks.
  
• Noisier Systems: Measuring system behaviors, like using response time for Blind SQL injection, is nearly impossible in an architecture based on message queues and load balancing.

The path forward 

The key is not to “just AI everything,” but to strategically use advanced methods to optimize decision-making. We at Detectify have already begun rolling out a couple of next-generation assessment updates to address this, with Dynamic Payload Rotation as a prime example for our API Scanner, and many more are planned for early next year.

This feature utilizes a near-infinite pool of payloads, mixing constant checks with experimental variations. If an experimental payload succeeds, it is immediately reused in future tests for that tech stack. This form of unsupervised machine learning allows the scanner to gain a permanent testing edge, ensuring that the fundamentals of state, payload, and assertion evolve as fast as the applications they protect.

The post Why traditional black box testing is failing modern AppSec teams appeared first on Blog Detectify.

This comparison focuses on how Holm Security and Detectify address the core challenges faced by AppSec teams: gaining visibility and context, testing their web applications and APIs, and how quickly users can get value from these tools. Holm Security offers broad, unified coverage across the entire IT estate (internal, external, and cloud) and relies on a proprietary unified risk score for strategic prioritization, making it a good consolidated risk reporting and management tool. Detectify, by contrast, is a specialized EASM and DAST solution focused on external applications. Detectify utilizes its Asset Classification to provide explicit scanning recommendations and employs 100% payload-based testing to ensure a high-fidelity signal, directly reducing friction and the time spent validating findings.

Detectify vs. Holm Security: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Holm Security users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Holm Security’s official website & resources
• Holm Security’s documentation
• Holm Security’s publicly accessible demos

The post Product comparison: Detectify vs. Holm Security appeared first on Blog Detectify.

Welcome to The researcher’s desk  – a content series where the Detectify security research team conducts a technical autopsy on vulnerabilities that are particularly interesting, complex, or persistent. For this issue, we look at CVE-2025-64446, a critical authentication bypass that has been actively exploited in the wild, targeting Fortinet’s Web Application Firewall (WAF) product, FortiWeb.

The Case File: Unauthenticated control

What’s the root cause of CVE-2025-64446?

The core issue is a complex Unauthenticated Authentication Bypass flaw. It involves an improper handling mechanism within the FortiWeb appliance that is related to user impersonation functionality.

Essentially, the vulnerability allows an attacker to manipulate the way the system validates user identity, tricking the appliance into granting administrative privileges. The flaw is rooted in how a function intended to handle user context is improperly exposed or protected, enabling its misuse for unauthorized access.

What’s the mechanism behind CVE-2025-64446?

The mechanism involves bypassing the standard login procedure to gain full administrative privileges on the FortiWeb appliance.

• Bypass the gate: The attacker first leverages a mechanism (reported as a Relative Path Traversal combined with a logic flaw) to reach a restricted executable or API endpoint on the FortiWeb device.
• Impersonation: Once the endpoint is reached, the attacker sends specially crafted input (often within an HTTP header) containing fields designed to impersonate the built-in admin account.
• Complete compromise: The appliance’s authentication function processes this untrusted input and grants the attacker an administrative context. This allows the attacker to execute administrative commands, often leading to the creation of a new, persistent administrator account with known credentials, which grants complete control over the WAF.

This flaw is interesting because it showcases the danger of authentication logic errors and how seemingly internal, administrative functions (like impersonation) can be weaponized when not properly secured. The flaw was exploited in attacks before a public patch was available, confirming its zero-day status.

Defensive takeaways

• Patching: Fortinet issued updates to resolve this vulnerability. Users must apply the security patch immediately to all affected FortiWeb versions.
• Management Access: Review the administrative user list for any new, unknown, or unauthorized accounts created since the beginning of October 2025 on the VPN appliance as a sign of compromise.
• The Detectify Approach: Detectify customers are running payload-based tests to check for the specific combination of path manipulation and header injection required to trigger this unauthenticated authentication bypass, providing early warning for vulnerable assets.

Questions? We’re happy to hear from you via support@detectify or book a demo to learn more about Detectify.

References

• https://nvd.nist.gov/vuln/detail/cve-2025-64446
• https://www.bleepingcomputer.com/news/security/fortinet-confirms-silent-patch-for-fortiweb-zero-day-exploited-in-attacks/
• https://labs.watchtowr.com/when-the-impersonation-function-gets-used-to-impersonate-users-fortinet-fortiweb-auth-bypass/
• https://blog.qualys.com/vulnerabilities-threat-research/2025/11/14/unauthenticated-authentication-bypass-in-fortinet-fortiweb-cve-2025-64446-exploited-in-the-wild

The post The researcher’s desk: FortiWeb Authentication Bypass (CVE-2025-64446) appeared first on Blog Detectify.

Welcome to The researcher’s desk  – a content series where the Detectify security research team conducts a technical autopsy on vulnerabilities that are particularly interesting, complex, or persistent. The goal here is not to report the latest research (for which you can refer to the Detectify release log); it is to take a closer look at certain vulnerabilities, regardless of their disclosure date, that still offer critical lessons.

For this issue, we analyze CVE-2025-59287, a critical remote code execution (RCE) flaw in Microsoft Windows Server Update Services (WSUS) that targets the core patch management infrastructure of the enterprise.

The Case File: WSUS Unauthenticated RCE

What’s the root cause of CVE-2025-59287?

The access flaw, CVE-2025-59287, is due to unsafe deserialization of untrusted data in the WSUS reporting/web services.

This means the service accepts data sent by an external source and fails to validate its structure or content safely before processing it. This fundamental failure allows an attacker to inject arbitrary code instructions into the data stream that the service then executes.

What’s the mechanism behind CVE-2025-59287?

The mechanism enables a high-impact attack due to its low requirements and high privileges.

• Unauthenticated Access: Attackers can send specially crafted events to unauthenticated endpoints of the WSUS service.
• Arbitrary Code Execution: The unsafe deserialization flaw allows the attacker to execute arbitrary code remotely.
• Privilege: This code executes with SYSTEM privileges on the target server, providing the highest level of control.

This flaw is interesting because it is actively exploited in the wild and targets core update management infrastructure in enterprises. It has been used to deploy infostealers and pre-ransomware payloads, which compromises sensitive data in regulated environments. The existence of public PoC exploits also accelerates the threat landscape.

Defensive takeaways

• Patching: Apply vendor updates to mitigate this vulnerability.
• The Detectify Approach: Detectify customers are running payload-based assessments to test for this vulnerability.

Questions? We’re happy to hear from you via support@detectify or book a demo to learn more about Detectify.

The post The researcher’s desk: CVE-2025-59287 appeared first on Blog Detectify.

This review provides a direct comparison between two external security platforms, Halo Security and Detectify. The analysis will focus on three core areas critical to Application Security engineers: Visibility and Context, which examines how each platform discovers and classifies assets; Assessment, which compares their technical methodologies for finding vulnerabilities; and Usability, which evaluates the day-to-day workflow and operational efficiency of each tool.

Detectify vs. Halo Security: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Halo Security users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Halo Security’s official website & resources
• Halo Security’s documentation
• Halo Security’s publicly accessible demos

The post Product comparison: Detectify vs. Halo Security appeared first on Blog Detectify.

For Application Security leaders and engineers, the choice between Rapid7 and Detectify is a decision between two fundamentally different philosophies: a broad, SOC-centric platform versus a purpose-built, practitioner-focused tool. Rapid7 presents a unified solution that correlates application flaws with holistic infrastructure risk, while Detectify is engineered exclusively for the external AppSec workflow. This analysis has compared both platforms through the three core use cases that matter to an AppSec team: their approach to visibility and attack surface discovery, the technical methodology and effectiveness of their assessment engines, and the practical usability of each tool in a modern, fast-paced remediation pipeline.

Detectify vs. Rapid7: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Rapid7 users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Rapid7’s official website & resources
• Rapid7’s documentation
• Rapid7’s publicly accessible demos

The post Product comparison: Detectify vs. Rapid7 appeared first on Blog Detectify.

This comparison reviews two security platforms, Detectify and Invicti, both engineered to provide vulnerability assessment and attack surface management. While both platforms compete, Detectify is built on a forward-looking philosophy, leveraging its proprietary, payload-based scanning engine and a multi-source intelligence model. This approach is powered by a private community of elite ethical hackers (Detectify Crowdsource), an AI researcher, and an internal team, enabling it to find the novel, non-CVE vulnerabilities that other tools miss. In contrast, Invicti’s value is rooted in its “Proof-Based Scanning” engine, an approach focused on confirming publicly known vulnerabilities, which requires a significant upfront time investment for configuration and cannot scan for emerging, 0-day threats. This core difference in assessment philosophy steers the platforms’ respective value, usability, and the day-to-day workflow for an AppSec team.

Detectify vs. Invicti: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients of Invicti who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Invicti’s official website & resources
• Invicti’s documentation
• Invicti’s publicly accessible demos

The post Product comparison: Detectify vs. Invicti appeared first on Blog Detectify.

Welcome to The researcher’s desk – a content series where the Detectify security research team will conduct a technical autopsy on vulnerabilities that are particularly interesting, complex, or persistent. The goal here is not to report the latest research (for which you can refer to the Detectify release log); it is to take a closer look at certain vulnerabilities, regardless of their disclosure date, that still offer critical lessons. 

For our first case file, we examine the exploit chain targeting Cisco ASA and FTD firewalls, beginning with the unauthenticated access flaw, CVE-2025-20362.

The case file

• Disclosure Date: September 25, 2025
• Bypass Flaw: CVE-2025-20362 with CVSS 6.5
• Execution Flaw: CVE-2025-20333 with CVSS 9.9
• Vulnerable Component: VPN Web Server on Cisco ASA/FTD
• Final Impact: Unauthenticated Remote Code Execution (RCE)
• Observations: Flaws were actively exploited as zero-days before patches were available

What’s the root cause of CVE-2025-20362? 

The access flaw, CVE-2025-20362 (Missing Authorization, CWE-862), is essentially a failure in user input validation, typically manifesting as a Path Traversal/Normalization issue.

When an attacker sends a carefully crafted HTTP request containing specific directory traversal sequences, the VPN web server’s logic fails to correctly identify the request as unauthenticated. Instead, the server’s authorization component is bypassed, treating the request as if a session already exists. This grants the remote attacker access to critical, restricted URL endpoints—endpoints that are not designed for public interaction.

What’s the mechanism behind CVE-2025-20362? 

The primary lesson of this case is chainability. While CVE-2025-20362 alone carries a moderate score, its true severity is realized when it is used to nullify the only defense protecting the second vulnerability, CVE-2025-20333 (a Buffer Overflow).

1. Latch Opened. The attacker uses a crafted request to exploit the input validation flaw CVE-2025-20362, bypassing the need for a login. 
2. Execution Delivered. The attacker then targets the now-exposed critical endpoint with the payload designed to trigger the Buffer Overflow CVE-2025-20333. (CVE-2025-20333 alone requires valid VPN credentials)
3. Result: The chain achieves Unauthenticated Remote Code Execution with privileges on the firewall: a complete takeover of the network perimeter.

Our team chose this flaw because it is an excellent example of a modern, high-stakes attack. The entire chain has been leveraged by sophisticated, state-sponsored campaigns, demonstrating that attackers prioritize the easiest way in, often starting with a moderate-severity bypass to unlock a critical vulnerability. It proves that defenders must identify and fix every link in a potential chain, not just the high-score vulnerabilities. 

Defensive takeaways

• Patching: Immediately upgrade to the latest, fixed Cisco releases.
• Segment and Isolate: If possible, restrict administrative and VPN web server access to only trusted IPs via upstream ACLs.
• The Detectify Approach: Detectify customers are running payload-based testing to check for the precise input normalization failure of CVE-2025-20362. 

Questions? We’re happy to hear from you via support@detectify or book a demo to learn more about Detectify.

The post The researcher’s desk: CVE-2025-20362 appeared first on Blog Detectify.

This comparison reviews two modern security platforms, ProjectDiscovery and Detectify, both engineered to provide high-signal, low-noise vulnerability assessment and attack surface management. While both are effective, they are built on fundamentally different philosophies. ProjectDiscovery is a platform where its value is rooted in its powerful open-source tools, like the Nuclei engine, which offer self-serve customization for newly disclosed public CVEs. In contrast, Detectify’s value lies in its proprietary, payload-based scanning engine , which is uniquely powered by a private community of elite ethical hackers (Detectify Crowdsource) to find novel, non-CVE vulnerabilities. This core difference in approach steers their respective strengths in assessment, usability, and the day-to-day workflow for an AppSec team.

Detectify vs. ProjectDiscovery: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients of ProjectDiscovery who decided to evaluate Detectify as its alternative, but also based on the following sources:

• ProjectDiscovery’s official website & resources.
• ProjectDiscovery’s documentation.
• ProjectDiscovery’s publicly accessible demos.

The post Product comparison: Detectify vs. ProjectDiscovery appeared first on Blog Detectify.

Choosing the right tool is a critical decision that depends on a team’s specific goals, resources, and technical focus. This review provides an in-depth comparison of two leading platforms, Escape and Detectify, to help you make an informed choice. We will explore how each tool approaches three core pillars of any effective AppSec program: Visibility (discovering and understanding your attack surface), Assessment (accurately finding vulnerabilities), and Usability (ensuring the tool is efficient and enjoyable to use). By the end of this comparison, you will have a clear understanding of each platform’s strengths and weaknesses, enabling you to determine which solution is the better fit for your team’s unique operational style—whether you need a tool built for deep, customizable analysis or one optimized for speed and decisive, guided action.

Detectify vs. Escape: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Escape users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Escape’s official website & resources
• Escape’s documentation
• Escape’s publicly accessible demos

TL;DR

The post Product comparison: Detectify vs. Escape appeared first on Blog Detectify.

The difference between Detectify and Tenable lies in their core scope and the use cases they support. Detectify is a specialized, attacker-centric platform designed for the application security practitioner. Its focus is exclusively on the external, internet-facing attack surface with Dynamic Application Security Testing (DAST) to find exploitable vulnerabilities in web applications and APIs. In contrast, Tenable is a comprehensive exposure management platform built for the entire security and risk organization. It provides a holistic view of risk across the entire IT estate—from internal servers and cloud infrastructure to identity systems and the external perimeter—positioning itself as the central nervous system for enterprise-wide vulnerability and risk management.

Their differing scope dictates their strengths. Detectify’s primary advantage for an AppSec team is the high-fidelity, low-noise nature of its findings. Its unique reliance on payload-based testing, powered by a crowdsourced network of elite ethical hackers, delivers results that prove exploitability and are immediately actionable. This builds credibility with development teams and streamlines the remediation workflow, which is a significant usability win. Tenable’s strength lies in its unmatched breadth of coverage and its powerful risk contextualization through the Vulnerability Priority Rating (VPR) and Attack Path Analysis. It excels at showing how an application fits into an org’s risk profile, making it an indispensable tool for compliance and enterprise risk management.

Detectify vs. Tenable: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Qualys users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Tenable’s official website & resources
• Tenable’s documentation
• Tenable’s publicly accessible demos

TL;DR

The post Product comparison: Detectify vs. Tenable appeared first on Blog Detectify.

Your responsibilities cover the full spectrum of risk—from the applications your teams build and the products you ship to the overarching compliance mandates you must meet. The core challenge is achieving this with a lean team where every hour of engineering time is critical. Choosing the right tooling is not just a technical decision; it’s a strategic one that directly impacts your team’s efficiency and your organization’s security posture.

This review provides an in-depth, practical comparison of Qualys and Detectify across three critical dimensions for a security leader:

• Visibility and Context: How well does it discover your complete attack surface and help you understand what’s important?
• Vulnerability Assessment: How effective is it at finding truly exploitable vulnerabilities versus creating triage overhead?
• Usability: Does the tool act as a force multiplier for your team or an operational burden?

Detectify vs. Qualys: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Qualys users who decided to evaluate Detectify as it alternative, but also based on the following sources:

• Qualys’ official website & resources
• Qualys’ documentation
• Qualys’ publicly accessible demos

TL;DR

The post Product comparison: Detectify vs. Qualys appeared first on Blog Detectify.

Choosing the right DAST tool is a critical decision that shapes the effectiveness of their entire program. Detectify and Burp Suite Enterprise, exemplify the innovation happening in this space. While both are powerful assessment tools, they are engineered to solve different core problems, stemming from fundamentally different approaches to visibility, vulnerability assessment, and usability. Understanding these differences is key to selecting the platform that aligns with your team’s specific needs, maturity, and security goals.

This comparison breaks down the core philosophies of each tool. Detectify operates on an “outside-in” model, starting with the crucial question: “What is my complete external attack surface?” It combines attack surface discovery with payload-based testing sourced from elite ethical hackers, the AI agent Alfred, and its internal security research team to provide immediate visibility and high-confidence, actionable findings. In contrast, Burp Suite Enterprise follows an “inside-out” model, built to answer: “Is this specific application I already know about secure?” It provides a powerful, highly customizable DAST scanner for mature security teams to perform deep, exhaustive scans on a known set of assets, prioritizing granular control and comprehensive coverage over automated discovery and ease of use.

Detectify vs. Burp Enterprise: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Burp Enterprise users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Burp’s official website & resources
• Burp’s documentation
• Burp’s publicly accessible demos

TL;DR

The post Product comparison: Detectify vs. Burp Enterprise appeared first on Blog Detectify.

This guide will explore the key distinctions between Nessus and Detectify, two products built to solve different problems. We’ll compare their core visibility, assessment methodologies, and approaches to modern web apps and API security.

The primary difference between the two products lies in their core focus. Nessus focuses on infrastructure vulnerability scanning, where they have prioritized  performing deep, authenticated scans on internal assets like servers and workstations. Nessus’ strength is its massive plugin library, which is ideal for patch management and compliance auditing. However, its web application scanning is a newer, less specialized feature, and its external scans are signature-based, which can create a high volume of false positives and triage work for an Application Security team.

Detectify, in contrast, starts with giving users both the visibility and context about their attack surface, making it possible to test each and every asset, like modern web applications and APIs. Its key technical differentiator is its payload-based testing methodology, API scanner, and classification and recommendation system. By confirming exploitability with every finding, it reduces false positives and curbs the triage load. Detectify’s assessment capabilities are further enhanced by sourcing vulnerabilities from a private community of ethical hackers and an AI agent, allowing it to find novel and non-CVE issues.

Detectify vs. Nessus: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Nessus users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Nessus’ official website & resources
• Nessus’ documentation
• Nessus’ publicly accessible demos

TL;DR

The post Product comparison: Detectify vs. Nessus appeared first on Blog Detectify.

Intruder is a cloud-based vulnerability scanner that provides an automated overview of an organization’s attack surface. Its primary function is to proactively identify weaknesses across internet-facing infrastructure and applications before they are exploited. The platform’s scanning engine runs a set of checks for both infrastructure-level misconfigurations and application-layer vulnerabilities, like those in the OWASP Top 10. It leverages open-source engines like ZAP to execute its checks. 

For an application security team, Intruder offers a tradeoff between ease of use and granular control. The platform is user-friendly, but its options for fine-tuning scan configurations are limited. Furthermore, its continuous attack surface monitoring and testing capabilities, which are critical for securing externally-facing assets, are limited and primarily available only in its highest pricing tiers.

This document provides a direct comparison of Intruder and Detectify. The objective is to break down the key technical differentiators to help users make an informed decision.

Detectify vs. Intruder: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Intruder users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Intruder’s official website & resources
• Intruder’s documentation
• Intruder’s publicly accessible demos

The post Product comparison: Detectify vs. Intruder appeared first on Blog Detectify.

There’s often a lack of understanding when it comes to Dynamic Application Security Testing (DAST) as a methodology versus DAST as a tool. How do they relate to each other, and how do they differ? How does it relate to Attack Surface Management (ASM)? And how can AppSec teams take advantage of both? 

Below, we’ll take a look at how both DAST as a methodology and DAST as a tool relate to what we do at Detectify. More specifically, we’ll explain how Detectify’s solution applies DAST methodology to the full breadth of an attack surface, automating the heck out of application security testing. With these methods, we cover millions of domains before you’ve even had breakfast. 

Differences between manual and automated security testing

Dynamic Application Security Testing (DAST) is the methodology of testing an application from the outside, poking at it with a stick from a distance. DAST methodology probes and sends payloads to a running application and then checks if the application screams back to detect potential issues. 

In practice, pen-testers use manual DAST methodology when carrying out red team assignments. A pentester could also carry out a code review, which is the manual version of Static Application Security Testing (SAST).

The history of DAST tools

DAST tools have been available for over two decades, typically designed to combine crawling and fuzzing capabilities to test isolated applications. In a nutshell, DAST tools aim to implement hacking methodology in an automated way.

Testing isolated applications was effective when they were monolithic, encapsulating all functionality (think back to the good old days of a PHP monolith). However, with the rise of modern technology architecture, the boundaries of applications have become much blurrier. As a result, testing has become more challenging as functionality is now spread across various components, such as microservices and cloud components. It’s not uncommon for vulnerabilities to arise at the interfaces between these components, particularly when they interpret edge cases in different ways.

Many organizations only identify a limited list of top assets thought to contain the most sensitive data, the majority of the attack surface is left without any coverage

With this in mind, it’s no surprise that “traditional DAST” (in other words, DAST tools) tends to be designed in a very unscalable way. Traditional DAST tools often offer the equivalent of one scan profile per application or IP in an attack surface. 

As we know, not all subdomains are created equal nor have the same lifespan. Additionally, a subdomain might not contain personally identifiable information (PII), but it might have unauthorized open ports or be susceptible to subdomain takeover.

Detectify can make your budget go further than “traditional” DAST tools can.

Surface Monitoring + Application Scanning = Best-in-class AST solution

At Detectify, we have taken DAST as a methodology and reinvented it as a method. But what does this mean, exactly?

To start, we use DAST methodologies in both our Surface Monitoring and Application Scanning products. Through using DAST methodology as the base for our platform, we’ve designed our solution to be highly scalable and provide customers with more value. 

Detectify goes beyond CVE matching by leveraging in-house built engines and vetted payloads in all tests accuracy rate. More than 30% of the tests we run do not have a CVE related to them. Instead, we focus on the payloads that are used in the wild.

More than 30% of the tests we run do not have a CVE related to them. Instead, we focus on the payloads that are used in the wild

We also take DAST another step further by utilizing crowdsource-fueled DAST. . Crowdsource focuses on the automation of vulnerabilities rather than fixing bugs for specific clients. Once our ethical hackers discover an accepted vulnerability in a widely used system such as a CMS, framework, or library, their reported findings are automated into our platform. By discovering undocumented security vulnerabilities through Crowdsource, we make it possible to go beyond the coverage of CVEs. 

Surface Monitoring

Surface Monitoring runs continuous checks on the domain level and offers added value by discovering assets you may not even be aware of as well as scanning those assets for vulnerabilities three times per day. The product can:

• Cover your entire public DNS footprint and can handle 100,000+ subdomains without any issues.
• Fingerprint your tech stack by mapping out the technologies you use to trigger only the most relevant security tests.
• Help teams set, enforce, and scale customizable security policies so you can focus on the issues that matter most.
• Run real-world, payload-based testing to discover misconfigurations and vulnerabilities in cloud infrastructure, content delivery networks (CDNs), and applications.  

Application Scanning

People often refer to our product, Application Scanning, as a DAST scanner. We go beyond the capabilities of a “traditional” DAST scanner by leveraging crawling, fuzzing, and authentication to find vulnerabilities in assets that normally can’t be reached through stateless testing. 

• We’ve built our scanner internally and have optimized it using learnings from our Crowdsource community.
• Our crawler handles single-page applications and filters large applications with repetitive content (such as media and e-commerce apps).
• Our powerful authentication engine securely implements MFA authentication and can replay user behaviors.

Go hack yourself

As we mentioned earlier on, we’ve taken DAST as a methodology and reinvented it as a method into ASM. With continuous practice of discovering and assessing Internet-facing assets and looking for their vulnerabilities and anomalies, Detectify forms a solution that gives you the most comprehensive coverage of your entire attack surface.

Discovering your organization’s unknown Internet-facing assets and then scanning them aren’t mutually exclusive (and shouldn’t be). That’s why you should take a more holistic approach to cover your attack surface. 

Get in touch with us to find out how your team can start reaping the benefits of both DAST and ASM.

The post How Detectify embraces the best of both DAST and ASM appeared first on Blog Detectify.

At Detectify, we help customers secure their attack surface. To effectively and comprehensively test their assets, we must send a very high volume of requests to their systems, which brings the potential risk of overloading their servers. Naturally, we addressed this challenge to ensure our testing delivers maximum value to our customers while being conducted safely with our rate limiter. 

After introducing our engine framework and deep diving inside the tech that monitors our customers’ attack surface, this Under the Hood blog post uncovers an important piece in the puzzle: how our rate limiter service works to make all Detectify scanning safe.  

The need for the rate limiter

In our previous post, we explained the techniques that we have in place to flatten the curve of security tests that an engine performs on our customers’ systems, avoiding spikes that could overload their servers. As we continuously add more security tests to our research inventory, and with several engines working simultaneously, one can imagine that the combined load from all tests could reach significant levels and potentially create issues for our customers.

To address this, we introduced a global rate limiter designed to limit the maximum number of requests per second directed at any given target. Sensible defaults are in place, and customers have the flexibility to configure this limit based on their needs.

The combined load of engines’ tests towards customers would increase unchecked without a rate limiter

The product requirements

Before jumping into the rate limiter solution, it was important to understand the requirements for our rate limiter. 

As a concept, rate limiting is nothing new in software engineering, and there are many tools available for addressing rate limiting challenges. However, we needed to determine if there was anything unique about our situation that would require a custom solution, or if an off-the-shelf product would suffice.

We explored several popular open-source tools and cloud-based solutions. Unfortunately, during our analysis, we could not find any option that fit our criteria. Detectify applies the limit on an origin basis (combination of scheme, hostname and port number), and needs to allow for individual target and highly dynamic configurations. Most existing tools fell short in this area, leading us to the decision to implement our own rate limiter.

Individual target rate limiting configurations, that can change at any time

The literature

Rate limiting is a well-known concept in software engineering. Although we built our own, we did not have to start from scratch. We researched various types of rate limiting, including blocking, throttling, and shaping. We also explored the most commonly used algorithms, such as token bucket, leaky bucket, fixed window counter, and sliding window counter, among others. Additionally, we looked into different topologies that we could use.

Our goal was to keep the implementation as straightforward as possible while meeting our requirements. Ultimately, we decided to implement a blocking token bucket rate limiter. Interestingly, given our security testing needs and how “deep in the stack” some security tests are, we landed on a service admission approach rather than the more common proxy approach.

In short, a blocking rate limiter denies requests to a target when the limit is exceeded. In contrast, throttling and shaping rate limiters manage requests by slowing them down, delaying them, or lowering their priority. The token bucket algorithm works by maintaining a “bucket” for each target which gets topped up on a clock with a number of tokens equal to reaching the limit in matter. Each request consumes a token from the bucket in order to be admitted. When the bucket runs out of tokens, the request is denied until the bucket is refilled. The service admission approach means that engines that want to perform a security test towards a target first need to get admission from the global rate limiter, while the proxy approach would work as a more transparent “middleware” for the request between the engine and the target.

Token bucket algorithm

The global rate limiter as an admission service

The technical choices

With the algorithm and topology defined, it was time to explore the technologies that could best meet our needs. The global rate limiter needs to handle a high throughput of requests with a significant level of concurrency, all while operating with very low latency and being scalable.

We further expanded on these requirements and determined that the solution should run in memory and involve as few internal operations as possible. E.g., leveraging atomic operations and simple locks with expiration policies. In the hot concurrency spot, we opted for a single-threaded approach that would run sequentially, avoiding the overhead of concurrency controls.

After discussing our options, we concluded that the best solution was to run the global rate limiter service on long-living ECS tasks backed by a Redis sharded cluster. Since we use AWS, we found it convenient to utilize ElastiCache for creating our Redis sharded cluster.

High-level design of our global rate limiter

Show me the code!

The global rate limiter service is rather straightforward, providing a simple API for requesting admission to a target. The more interesting aspect lies in the implementation of the token bucket algorithm between the service and Redis.

We aimed to leverage atomic operations and simple locks with expiration policies, while also running tasks sequentially in the areas of high concurrency. This sequential execution was straightforward with Redis, as it operates in a single-threaded manner. Our focus was to place the concurrency challenges onto it. The simple locks with expiration policies were convenient with Redis, as one of the areas it excels in. At this point, we just had to concentrate on designing the algorithm with as few service-Redis interactions and as atomically as possible. After some iterations, we settled on a solution that runs a Lua script on the Redis server. Redis guarantees the script’s atomic execution, which fits the bill perfectly.

Let’s have a look at the code, with detailed explanations following: 

local bucket = KEYS[1]
local tokens = ARGV[1]

local tokensKey = bucket..":tokens"
local lockKey = bucket..":lock"

local tokensKeyExpirationSec = 1
local lockKeyExpirationSec = 1

local admitted = 1
local notAdmitted = 0

local refilled = 1
local notRefilled = 0

if redis.call("decr", tokensKey) >= 0 then
return { admitted, notRefilled }
end

if redis.call("set", lockKey, "", "nx", "ex", lockKeyExpirationSec) then
redis.call("set", tokensKey, tokens - 1, "ex", tokensKeyExpirationSec)
return { admitted, refilled }
end

return { notAdmitted, notRefilled }

The script takes a few parameters: the bucket name and its limit value for the tokens. As for the time window, we are only working with 1-second time windows. Then, going into checking for admission, the first thing we do is to try and decrement a token from the bucket. If there are available tokens, we admit the request. Otherwise, we check if it’s time for refilling the bucket. To do that, we use Redis’s capability of setting the lock key if it does not exist and provide the 1-second time window as expiration time. If we manage to set the lock key, it means we have entered a new time window and can refill the bucket, which we do while returning the approval to proceed. If we didn’t have enough tokens, and we could not refill the bucket yet, we deny the request. The tokens key also has an expiration time so that we don’t have to do extra cleanups after requests towards a target haven’t happened in a while.

How is it performing?

We have been satisfied with the performance since its inception. On average, it handles 20K requests per second, with occasional peaks of up to 40K requests per second. The p99 latency is normally lower than 4 milliseconds, and the error rate nears 0%.

One interesting challenge related to observability is determining how many requests are performed towards a single target. For those familiar with time series databases, using targets as labels would not work, leading to an explosion in cardinality. An alternative could be to rely on logs and build log-based metrics, but if one looks at the volume that we are dealing with, they can imagine it would be extremely costly in financial terms.

To tackle this challenge, we had to think creatively. After some ideation, we decided to log at the moment the buckets get refilled. While this method doesn’t provide the exact number of requests made to a target, it does indicate the maximum number of requests that could be sent to a target at various points in time. This is the essential information for us, as it allows us to monitor and ensure we do not exceed the specified limits.

More engines and tests, safer customers  

Keeping our customers secure is about achieving the perfect technical balance to ensure a safe way of running security tests on their attack surfaces without causing unexpected load issues to their servers and potentially affecting their business. The implementation of our global rate limiter allowed us to safely increase the number of engines and security tests in our inventory, running more security testing without breaking their systems. 

From an engineering perspective, implementing a global rate limiter presents an interesting technical challenge, and we found a solution that works well for us. If any changes arise, thanks to the extensive ideation throughout the whole process, we are ready to adapt to ensure we provide a safe and reliable experience to our customers. That said, go hack yourself! 

Interested in learning more about Detectify? Start a 2-week free trial or talk to our experts.

If you are a Detectify customer already, don’t miss the What’s New page for the latest product updates, improvements, and new security tests.

The post Sending billions of daily requests without breaking things with our rate limiter appeared first on Blog Detectify.

The post How Detectify embraces the best of both DAST and EASM appeared first on Detectify Blog.

The post Should your team really run DAST in staging environments? appeared first on Detectify Blog.

The post 4 fundamental questions on EASM — and how Detectify’s solution answers them appeared first on Detectify Blog.