Web-Cache-Vulnerability-Scanner icon indicating copy to clipboard operation
Web-Cache-Vulnerability-Scanner copied to clipboard

Prevent reporting 401/429 responses

Open marcelo321 opened this issue 2 years ago • 3 comments

Hey there,

Is there any way to configure it in a way it doesn't report as valid cases these kind examples:

Reason: Status Code 403 differed from 200

or

Reason: Status Code 200 differed from 429

A lot of sites start giving code 429 or 403 when you make a lot of requests, and it makes a looot of noise of "valid" alerts of the scanner. Would be absolutely awesome to prevent reporting these cases.

marcelo321 avatar Jan 08 '24 05:01 marcelo321

Hello @marcelo321, that's a good point. We already have a check if the "default" status code changed, before reporting a different status code. However, this check may be flawed if you are experiencing such a behavior. I already looked at the code for the status code check for a short time and identified an improvement to implement. Maybe that will fix this. I'll look further into that when I have time for it.

m10x avatar Jan 08 '24 06:01 m10x

I just checked it more thoroughly and could replicate it using https://www.cloudflare.com/rate-limit-test/.

Typically it should work this way: If the poison and the benign request both result in the same status code, which differs from the default one, a third verification request is send. If this verification request also has the new status code, no vulnerability will be reported and it is set as the new default status code.

However: I could replicate these false positives. After some debugging I've found the issue. E.g. Default Status Code 200 -> 1. Poison Request = 429 (because of WAF ratelimiting) -> 2. Benign Request = 429 (still ratelimited) -> 3. Verification Request = 200 (because WAF ratelimiting let's this one through again) This way, the default status code is still 200 and a vulnerability is reported. I'm not quite sure what's the best solution to fix this. Maybe a "WAF-Sleep" flag which specifies how long wcvs will wait for, if a 429 is received. Also: Because of the multithreading this problem occurs more often. However using a lower thread count (e.g. 1) currently results in a dead lock.

The best current wait to circumvent is to use the --reqrate / -rr flag (Requests per second. Float value. Has to be greater than 0. Default value is infinite) in order to not get blocked by the WAF.

m10x avatar Jan 11 '24 08:01 m10x

@m10x this went through my messages and didn't see it.

For me personally I don't think there is a direct way of "fixing" this, there will be false positives and valid cases of 429 cache poisoning that are not false positive.

But imo I would just want a flag to discard the cases I don't want, e.g cache poisoning from code 429. I run this tool a lot and I get a lot of noise from the 429s

marcelo321 avatar Feb 01 '24 16:02 marcelo321

Sorry for taking so long! I'm implementing a "ignoreStatus" flag, which can take multiple status codes as parameter. E.g. -is 429,401 will tell wcvs to not report web cache poisoning if the poisoned status code is 429 or 401 OR if the default status code is 429 or 401 and changes to something else. It may also be useful to be able to specify a sleep time if a status code on the ignore list gets returned.

m10x avatar Mar 19 '24 13:03 m10x

You can check out the new release https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner/releases/tag/1.2.1 If you notice any room for improvement or have any other feedback, feel free to reopen the issue or to create a new one :) Greetings

m10x avatar Mar 20 '24 08:03 m10x