This is pretty clever. Nice work! Really illustrates how WAFs are extremely blunt tools.
Response Filter Denial of Service: shut down a website by triggering WAF rule
11–20 of 27 posts
Re: Response Filter Denial of Service: shut down a website by triggering WAF rule
#12It would seem Little Bobby Tables¹ now has a cousin, Denny DeDOS. I have worked with such filters at some point earlier in life and had completely forgotten about them. This article brought back weird memories. It seemed like a good idea at the time. I think. 1: xkcd://327
Excellent use of unicode.
Re: Response Filter Denial of Service: shut down a website by triggering WAF rule
#13I've seen legitimate ecommerce transactions blocked because WAF rejected the customer's address containing the word "Union" (which is also an SQL keyword.)
Re: Response Filter Denial of Service: shut down a website by triggering WAF rule
#14cloudflare firewall rule that I think will help protect against this:
(not http.request.uri.path contains "." and any(http.request.headers["content-range"][*] contains "bytes"))
you may have to modify for your needs
Re: Response Filter Denial of Service: shut down a website by triggering WAF rule
#15The attacker would also have to bypass the WAF while posting the trigger string, so perhaps it’s not trivial. Still, the whole design of these heuristic WAFs feel quite weak.
This is just plain wrong. A WAF rule meant to prevent credit card numbers from being output would not block the server from accepting credit card numbers. Or social security numbers, or any other kind of sensitive data. That would be wild. Blocking responses based on the content returned is pretty silly in the first place, but the whole point is to prevent the data from leaving, not from coming in. In fact the whole…
> This is just plain wrong. A WAF rule meant to prevent credit card numbers from being output would not block the server from accepting credit card numbers
Until you have any kind of JS code where the contents of an input box are round-tripped, so that the user enters a number and then either the interface brake so it starts getting blanked out against their will.
Re: Response Filter Denial of Service: shut down a website by triggering WAF rule
#16I’ve been working with WAF rules from OWASP ModSecurity recently and I’m honestly a little worried about it. It seems geared towards “securing” the worlds worst PHP app, but any reasonably good framework and infrastructure will weed out most of what these rules seem to be there to protect against, leading to silly false positives that become a whole lot less silly when it’s Big Customer whose requests are blocked. What do I know though, I’m just the guy who was told we need this. This isn’t advice against using preconfigured WAF rules, just my honest (and I’m sure naive) first impression
Re: Response Filter Denial of Service: shut down a website by triggering WAF rule
#17I've seen legitimate ecommerce transactions blocked because WAF rejected the customer's address containing the word "Union" (which is also an SQL keyword.)
The Scunthorpe problem absolutely affects WAF and IDS rules :(
Re: Response Filter Denial of Service: shut down a website by triggering WAF rule
#18I've seen legitimate ecommerce transactions blocked because WAF rejected the customer's address containing the word "Union" (which is also an SQL keyword.)
That's taking union busting to a new level.
Re: Response Filter Denial of Service: shut down a website by triggering WAF rule
#19Personally I feel a bit insulted that security can mandate a “tool” like this to “prevent” sql injections. Just because they are clowns doesn’t mean that we are.
Sorry users, the string “a > b” is not allowed any more. But fear not, “å > b” works just fine
Re: Response Filter Denial of Service: shut down a website by triggering WAF rule
#20I’ve been working with WAF rules from OWASP ModSecurity recently and I’m honestly a little worried about it. It seems geared towards “securing” the worlds worst PHP app, but any reasonably good framework and infrastructure will weed out most of what these rules seem to be there to protect against, leading to silly false positives that become a whole lot less silly when it’s Big Customer whose requests are blocked. Wh…
Yes. ModSecurity is best used as a tool for virtual patching, meaning something you can use to create a temporary defence for a problem you know you have. That buys you some time until the problem is fixed.
When you're writing a virtual patch you know exactly what data you're dealing with and you can allow through only what's known to be good. Any other approaches (e.g., generic rules) deal with text in bulk and are prone to false positives.
Even with this narrower focus, it's still a difficult problem. Here's a paper I wrote on this subject a while ago: https://blog.qualys.com/wp-content/uploads/2012/07/Protocol-...
Source: I am the original author of ModSecurity (but not of any of the rules packages).