Found a webshop once which issued IP bans when you triggered their WAF. Coincidentally, some product permalinks (containing the product name) triggered their WAF. Great conversion rate on those, I’m sure.
YOU HAVE BEEN BLOCKED FOR MALICIOUS ACTIVITY surely has to be good for business. Not that most would know, considering the trackers won’t load when this happens.
Even if they got the link, read it, they probably didn't fully understand the concepts.
I wish this was a joke, but just last month I spent literally hours arguing with multiple people -- on shore -- that that kind of query rewrite/rejection approach was never going to work properly, and only properly parameterised queries were correct.
Nope.
Fix after fix, then fixes for the fixes, then workarounds for the glitches, and then... on and on.
It was incredible to me that in 2023, supposedly senior technical team leads would have heated arguments rejecting parameterised queries and favouring regex WAF instead.
> query rewrite/rejection approach was never going to work properly, and only properly parameterised queries were correct
...what do you mean by "rewrite/rejection"?
If rewrite means "escaping strings using the database function designed for that purpose", then that approach works just fine. It's not comparable to rejection at all.
If they were making their own version, then the underlying problem is that they were making their own version. Parameterised queries are lovely but they are not the only option.
I mean that they were doing simple things like replacing a single quote (dangerous!) with a double single quote. E.g.: ' -> ''
That means that when a user called Bob O'Neill enters their name, instead of returning a HTTP/500 error, the database stores Bob O''Neill.[1]
Then when the user goes to edit their form, they will see O''Neill. Okay, oops, that's a mistake, let's just replace all double single quotes with a single quote when outputting HTML! Now it'll say O'Neil correctly!
Of course, if you enter some bad text with double single quotes via some other mechanism such as a CSV upload, there's a decent chance that'll it'll be incorrectly stripped. Perhaps in some mid-tier API, which will then interpret it as a single quote, resulting in an injection vulnerability (or data corruption) again.
That can be fixed with "mere" man months of effort instead of the minutes it would have taken to just use the parameterised queries like God intended.
Now that that nightmare is over once and for all... what to do about % symbols screwing up LIKE searches? I dunno, that's complicated, so let's just replace all...
... rinse, repeat, ad infinitum.
[1] Oh, oh, you assumed that the query engine would replace '' with ' and the database would store the correct text? Hah-haaa.... you assumed that this "fix" was applied only once! What's fun about band-aids is that they're so easy to accidentally layer three or four deep without even realising. More band-aids == more safe, am I right?
A common problem with technical leads is that occasionally they tend to forget that they can't know all the correct solutions and it's usually better to yield to those who do. Sometimes seniority makes this even worse.
Source: After so many years of dealing with bad technical decisions became a TL myself :)
"Needs to die" is a bit harsh but there are alternatives that are better and more secure. If you're just a regular sysadmin and only want to spend 8-9 hours a day at work you might just use a WAF instead and deal with the lost performance/added cost.
