We have Scanned the Web Server which is protected by WAF, but we found the result is different between Vulnerability Output VS The Actual Access via Browser. The actual access show it blocked, but the scanner result is not. I think it's same case with other customer machine before
Reply
The attack was a form POST, so it’s not possible to reproduce it by opening the URL in the attack string. Here is the output of the scanner
(POST): Lethal Attack Crawler Possible code execution: (https://site/?client=&&+/bin/password=1&zLoginField=1&loginOp=login)
The reflection of a user input in the output, especially when the output is a html form, should always be considered as a vulnerability and fixed. The solution is not reflect the user input in any part of the html sent back to the user after the POST.
Can you suggest how we can reproduce this to prove that it is not blocked by WAF?
It's necessary to see in the returning html if the reflected string is part, for example, of a form, and evaluate the danger case by case.
Comments
0 comments
Please sign in to leave a comment.