Technical Tip: How FortiDAST checks Vulnerabilities if WAF affects the scan

Considering a situation where the FortiDAST scans an application hosted behind a cloud/on-prem WAF.

The WAF can block the scan based on the policies configured, and FortiDAST will consider that as a vulnerability in the Application.

Screenshot refers to the access denied response by the WAF, and FortiDAST sees that as a Vulnerability.

Here is the corrected step-by-step breakdown of this flow:

1. Baseline Scan: First of all, the FortiDAST scanner loads a normal page from the application to establish a baseline. It saves the size (content-length) of this page for future comparison.
   
   
2. Attack Simulation: The FortiDAST scanner sends a request to the application containing a known SQL injection payload (e.g., or '1'='1') in the User-Agent header to test for a vulnerability.
   
   
3. WAF Interception & Redirect: If there is a WAF inline and it intercepts this malicious request. Instead of letting it reach the application, the WAF will block it and, as part of its blocking process, issue a redirect to its own standard 'Access Denied' page as per the WAF security policies.
   
   
4. FortiDAST Scanner's Misinterpretation:  The scanner will detect 2 things:

• Firstly, a redirect occurred.
• Second, after following the redirect, the new page's size did not match the original baseline page's size. The scanner's logic is programmed to interpret this specific combination, a redirect followed by a page content change, as a sign that its payload successfully manipulated the application.

So, the scanner correctly identified a change in the application's behavior (a redirect to a new page) but incorrectly attributed the cause. It concluded that this change was a symptom of a vulnerability within the application, when it was actually the result of the WAF successfully doing its job.

Note: This is a case study, where the scan is done by FortiDAST and sees a Vulnerability which is the result of a blocked request by WAF inline.