How to read a Pentest/DAST finding?

How does the PenTest/DAST Scanner work?

DAST tools interact with a running application by simulating real-world attacks. They send various inputs (malicious or otherwise) to the application’s endpoints and analyze the responses to identify potential vulnerabilities. Here’s a simplified view:

1. Crawling/Spidering: The DAST tool starts by crawling the application to discover all its accessible URLs, forms, and parameters.
2. Attack Simulation: The tool then starts sending various types of requests designed to trigger specific vulnerabilities. Common attack types include:
  - SQL Injection: Sending malicious SQL code in form fields or URL parameters.
  - Cross-Site Scripting (XSS): Sending JavaScript code that could be executed by another user’s browser.
  - Command Injection: Sending operating system commands that the application might execute.
  - Directory Traversal: Trying to access files or directories outside of the application’s intended scope.
3. Response Analysis: The DAST tool analyzes the application’s responses for indicators of a vulnerability. These indicators might include:
  - Error messages containing database details or internal application information.
  - Unexpected behavior, like the ability to access unauthorized files.
  - Execution of injected code (e.g., seeing JavaScript code injected via XSS execute in the DAST tool’s browser).
4. Reporting: The DAST tool generates a report listing all the vulnerabilities it has found, along with information about the affected URLs, the type of attack that triggered the vulnerability, and often remediation advice.

Who Decides it’s a Vulnerability?

DAST tools use the same industry standards as SAST, and they try to exploit the running application and observe the response. Again, human experts analyze the reports to make the final determination and fix any possible flaws.

DAST (Dynamic Application Security Testing) tools test your running application from the outside to simulate real-world attacks and detect vulnerabilities in behavior and configuration.

Issue Title: Commonly includes the type of vulnerability (e.g., “Cross-Site Scripting”, “Insecure Cookie”).
Severity: Indicates risk level, often aligned with OWASP Top 10 issues.
Description: Explains the vulnerability, why it matters, and what harm it can cause.
Proof of Concept: Demonstrates how the flaw can be exploited.
URL & Parameter: Specifies the endpoint and input field involved.
Request/Response: Shows the HTTP request sent and the vulnerable response received.
Remediation Advice: Practical guidance to fix the issue (e.g., encode outputs, set secure flags).

Tip: Focus first on authenticated or sensitive endpoints and verify that the issue is not a false positive before acting.