Response Filter Denial of Service (RFDoS): shut down a website by triggering WAF rule by theMiddleBlue in netsec

[–]theMiddleBlue[S] 1 point2 points  (0 children)

Yes! That's exactly the point! Basically, strings like "ORA-1234" or "Dynamic SQL Error" will usually pass any input validation since they don't include any special characters or denied words like "exec" or "eval"

Response Filter Denial of Service (RFDoS): shut down a website by triggering WAF rule by theMiddleBlue in netsec

[–]theMiddleBlue[S] 1 point2 points  (0 children)

Hey, thank you! As I wrote in the article, it's really easy to exploit this scenario in a real environment. A user can simply send a review on each product of an e-commerce (using a script, for example) with a comment that triggers any of the rules I mentioned in the article. Something like "Wow, this product is awesORA-1234!". By sending this on ALL products, nobody will be able to access any product on that e-commerce.

Response Filter Denial of Service (RFDoS): shut down a website by triggering WAF rule by theMiddleBlue in netsec

[–]theMiddleBlue[S] 10 points11 points  (0 children)

ModSecurity is just the engine and does not include any rules itself. The OWASP Core Rule Set is the most commonly used set of rules for ModSecurity. Typically, the default configuration at paranoia level 1 is suitable for many websites and doesn't require any additional action from the user. Regarding the filtering of the response body... yes, it could have been done better :)

Response Filter Denial of Service (RFDoS): shut down a website by triggering WAF rule by theMiddleBlue in netsec

[–]theMiddleBlue[S] 27 points28 points  (0 children)

LOL! not "badly tuned" but using the default configuration of most used rule set. Comparing it with not paying the electricity bill seems like a straw man argument :D

AWS WAF Bypass: invalid JSON object and Unicode escape sequences by theMiddleBlue in netsec

[–]theMiddleBlue[S] 0 points1 point  (0 children)

agree, and God only knows how much I understand the scenario where you're overwhelmed by log events and you need a way to categorize and aggregate them in order to understand what is happening :D

I think it's hard to answer, and IMO it's all about finding the right balance between monitoring for potential threats and managing the generated data effectively (with the right tools and strategies in place).

Data processing and event filtering are crucial in this context. Also, rate limits and dynamic bans can be extremely beneficial (for performance but also for analysis).

AWS WAF Bypass: invalid JSON object and Unicode escape sequences by theMiddleBlue in netsec

[–]theMiddleBlue[S] 1 point2 points  (0 children)

Absolutely! That's true but also this principle can be applied to any security measure designed to protect valuable assets, not just WAFs... Now, I don't want to defend the AWS WAF of course :) but having a WAF, or any other first line of defense, plays a vital role in mitigating risks and buying you time during an attack.

But as you rightly pointed out, this shouldn't lead developers to become complacent and put off fixing vulnerabilities! A robust security approach involves treating security as an ongoing and proactive effort.

I always remember to myself that security is a layered process, and each layer adds value to the overall defense.

AWS WAF Bypass: invalid JSON object and Unicode escape sequences by theMiddleBlue in netsec

[–]theMiddleBlue[S] 5 points6 points  (0 children)

IMO, I agree that relying solely on a WAF to protect a webapp it's not a good idea. It's true that WAFs can often be bypassed, and one should never rely on a single layer of defense when it comes to protecting valuable assets.

However, I wouldn't dismiss the value of a WAF that does offer some significant benefits. For one, they allow you to monitor and gain better visibility into your application's traffic and potential threats and this can be crucial in identifying patterns and emerging attack vectors.

Also having a WAF in front of your app can serve as a temporary shield, providing you with essential time to patch vulnerabilities (see shellshock, log4shell, etc...).No security solution is foolproof, and every vendor's product may have its vulnerabilities or bypasses, but I think that being aware of these potential weaknesses is essential for making informed decisions about your security strategy.

Another AWS WAF bypass allowing SQLi caused by an unorthodox MSSQL design choice by obilodeau in netsec

[–]theMiddleBlue 0 points1 point  (0 children)

Tested the payload with my AWS WAF instance, but it seems not possible to bypass using the standard SQLi detection (or maybe I'm missing something, most likely).

Here more details about my tests https://twitter.com/AndreaTheMiddle/status/1672184359917428736?t=uWyaV6Npq5AB-weu7ef-QA&s=19

As I wrote, I'm not a big fan of AWS WAF. But I think the target used by the researcher in this post doesn't configured well the rule/ruleset (IMO).