5 ms·
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 fe
by klabb3 2y ago
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.
- yencabulator 2y agoThe 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.
- hyperpape 2y agoThe consequence of this post is that it very much does! Though I would just leave those strings out of the WAF.
- bastawhiz 2y agoThis 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.
- derefr 2y ago> 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?
- bastawhiz 2y agoI don't disagree, but also blocking incoming requests that contain ops secrets gives you a great oracle for brute forcing what those secrets are!
- derefr 2y agoI 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.])
- Terr_ 2y ago> 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.
- bastawhiz 2y agoThat's literally just a variant of the issue being described here.
- svieira 2y agoPreventing 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).