| Solution |
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:
- 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.
- 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.
- 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.
- 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.
|
