-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Break out Blind/Timing Based Injections To Separate Rules #7341
Comments
I definitely like the idea of people being able to disable all of these checks in one go. |
Just splitting into their own scan rules and keeping them in the same add-ons sounds better. |
We could tag them as well? |
Definitely. |
Do you mean with Alert tags? Or do you mean with Tech as you originally suggested? If you mean Alert tags then yes definitely. |
I thought that was for the rules themselves, but in the alerts it works as well. |
We've discussed this on IRC and we like the idea of splitting the timing checks into different rules, but keeping them in the same add-ons. The alert tags would be a bonus... |
I've updated the first comment with a list of all the rules that I could find which perform timing based attacks - anyone think of any that I've missed? |
In my opinion that shouldn't be the solution to the time attacks fps. My suggested solutions are: improving the time delay detection logic by making an unique method in the common lib that would deal with the maths and number of requests, don't run time based if confidence is high, use several detection methods (delay, reflection, error) simultaneously and if more than one work increase confidence. Some disadvantages of splitting the rules:
|
Thanks for the conversation here. I'm going to bounty each of these tasks to get some 💵 associated with this work. |
Great to see the PR (zaproxy/zap-extensions#4316) is making it's way through. I'm also seeing a high number of false positives from timing based attacks and looking forward to this change. Let me know if there are outstanding items to get this done that need to be picked up and I can try to help out with them. Thanks! |
Hi ZAP team - checking in to see if this is still planned? |
Yes but still pending on fixes being done to the scan rules. |
Move time based tests to its own rule, ID 90039. Part of zaproxy/zaproxy#7341. Signed-off-by: wapmon <wapmon@aol.com>
Move time based tests to its own rule, ID 90039. Part of zaproxy/zaproxy#7341. Signed-off-by: wapmon <wapmon@aol.com>
Move time based tests to its own rule, ID 90039. Part of zaproxy/zaproxy#7341. Signed-off-by: wapmon <wapmon@aol.com>
Move time based tests to its own rule, ID 90039. Part of zaproxy/zaproxy#7341. Signed-off-by: wapmon <wapmon@aol.com>
Move time based tests to its own rule, ID 90039. Part of zaproxy/zaproxy#7341. Signed-off-by: wapmon <wapmon@aol.com>
Hi thc202 anything we can do to help get this through the finish line? I could either try to pick it up or potentially sponsor a member of the ZAP team to work on it. |
Ticked the ones that were already done, there's also a status in #8112 (comment) |
Which ones are a priority? |
Thanks, I'd missed that some were already done. We'll review and see if any others are still a priority |
Is your feature request related to a problem? Please describe.
In at least the SQL Injection (40018) and OS Command Injection (90020) plugins, there are definitive attack/response detections and non-definitive attack/responses usually assigned with blind injection attacks. Those attacks attempt to perform a sleep injection to control the applications timing and perform StdDev work on the responses to see if they were successful.
The timing based alerts consistently generate False Positives due to a handful of factors, one of them being the application is under heavy load. This makes troubleshooting and diagnosis very hard.
Describe the solution you'd like
Proposal is to break out those blind attacks to their owns plugins so they can be optimized.
Describe alternatives you've considered
Screenshots
No response
Additional context
No response
Would you like to help fix this issue?
Update - the rules that perform timing based attacks
The text was updated successfully, but these errors were encountered: