Live data from Hacker News

Response Filter Denial of Service: shut down a website by triggering WAF rule

blog.sicuranext.com

1–10 of 27 posts

Re: Response Filter Denial of Service: shut down a website by triggering WAF rule

#3
It 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

Re: Response Filter Denial of Service: shut down a website by triggering WAF rule

#5
post #4

The 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.

The component that's meant to prevent a debug message from spilling the naughty bits has no reason to inspect data flowing in the other direction.

Re: Response Filter Denial of Service: shut down a website by triggering WAF rule

#6
post #4

The 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 reason the rules exist is to prevent the case where your database starts burping up data you don't want it to. But if you were blocking the data from being accepted in the first place you wouldn't have that data in your database to begin with.

Re: Response Filter Denial of Service: shut down a website by triggering WAF rule

#7
post #4

The 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.

The component that's meant to prevent a debug message from spilling the naughty bits has no reason to inspect data flowing in the other direction.

The consequence of this post is that it very much does!

Though I would just leave those strings out of the WAF.

Re: Response Filter Denial of Service: shut down a website by triggering WAF rule

#8
post #4

The 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…

> But if you were blocking the data from being accepted in the first place you wouldn't have that data in your database to begin with.

I mean, many of these dumb mistakes that someone would want their WAF to save them from, wouldn't be for leaks of user-provided PII, but rather for leaks of ops-provided secrets (e.g. connection credentials for upstream APIs), no?

Re: Response Filter Denial of Service: shut down a website by triggering WAF rule

#9
post #4

The 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.

Preventing users from submitting things that look like error messages sounds like a good idea until you stop a user from using your contact form to submit an error message that they just actually encountered on your website (because your WAF is set up incorrectly).
Post reply on HN