Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.sicuranext.com

Post reply on HN
Print view View original

21–27 of 27 posts

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

#21

Post by bastawhiz »

Terr_ wrote: post #15
bastawhiz wrote: post #6

Earlier quoted context omitted.

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.

That's literally just a variant of the issue being described here.

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

#22

Post by bastawhiz »

derefr wrote: post #8
bastawhiz wrote: post #6

Earlier quoted context omitted.

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?

I don't disagree, but also blocking incoming requests that contain ops secrets gives you a great oracle for brute forcing what those secrets are!

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

#23

Post by corytheboyd »

ivanr wrote: post #20
corytheboyd wrote: post #16

I’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…

Oh yeah I can see the place for it, thanks for filling in that context, and only on HN would the original author of ModSecurity see my comment about it haha!

For my context, I’m coming from a place of adding it to very new deployments, where the needs are constantly changing, which is why it feels a bit square-peg-round-hole I think.

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

#24

Post by kypro »

corytheboyd wrote: post #16

I’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…

I'm in exactly the same boat, and I 100% agree. The OWASP ModSec rules are insanely naive, and generally your only option when you run into false positives will be to disable the rule altogether.

I think ideally you'd want to use the rules to create some kind of temporal risk score for a given IP / client. Eg, if a single IP hits your service several times in 5 minutes with suspicious requests, then you block the request. But this isn't possible so you basically have to ensure all your rules are only looking for the most obvious and suspicious requests, otherwise you're going to get far too many false positives.

The only argument I could make in favour of using it is a lot of attacks these days are automated and therefore are quite naive because they're simply poking around for holes.

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

#25

Post by akira2501 »

blueflow wrote: post #2

Hilarious. I love this. This is the same kind of "safety measure actually increases attack surface" like antivirus programs.

That there is still a market for "security as an afterthought" is bothersome.

All additions to a system inherently increase risk and require thoughtful alterations to existing preventative maintenance and disaster recovery planning, but the price of these products and their attendant marketing often leave no room for this to actually occur.

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

#26

Post by derefr »

bastawhiz wrote: post #22
derefr wrote: post #8

Earlier quoted context omitted.

> 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?

I don't disagree, but also blocking incoming requests that contain ops secrets gives you a great oracle for brute forcing what those secrets are!

I think I'd expect it to block responses containing anything matching the syntax of any ops secret.

A bit like how Github's partner leaked-secret scanning system works (where each company concerned with credential leaks, registers with Github the syntax of the credentials they issue as a regex pattern — and then Github webhooks the relevant company whenever one of their issued credentials makes it into a commit on any public repo, so that they can invalidate that secret before some attacker scrapes it out of the repo and plugs it into their botnet.)

But rather than the credential issuers registering their secret formats with the WAF, instead it'd just be your ops team telling the WAF the general-form regexes for each type of secret your team is actually using in prod. (Which might be a bit hard to determine from an ops team's position, as they may not have too many examples of a given type of secret — but it's usually a safe bet that your secret is just a concatenation of constant string parts with fixed-length baseN-alphabet parts. So in practice it's mostly just a matter of recognizing what N is [and maybe the variant alphabet in use, in the case of e.g. base32.])

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

#27

Post by sebazzz »

elevation wrote: post #13

I've seen legitimate ecommerce transactions blocked because WAF rejected the customer's address containing the word "Union" (which is also an SQL keyword.)

I know of at least one Azure Application Gateway (which is a WAF) where the company-wide policy is to enable all the Rules, even the ones Microsoft says not to enable.

This results in fun debugging sessions for issues, where random requests are blocked, also often redirects from Azure AD logins where it apparently triggers on the JWT token.

Post reply on HN