upvote

points

by krferriter3 days ago |
comments
upvoteby immibis2 days ago|
next
[-]
Because someone said "we need security" and someone else said "what is security" and someone else said "SQL injection is security" and someone looked up SQL injections and saw the word "select" and "insert".

WAFs are always a bad idea (possible exception: in allow-but-audit mode). If you knew the vulnerabilities you'd protect against them in your application. If you don't know the vulnerabilities all you get is a fuzzy feeling that Someone Else is Taking Care of it, meanwhile the vulnerabilities are still there.

Maybe that's what companies pay for? The feeling?

reply
upvoteby patrakov1 days ago|
parent|
next
[-]
> If you knew the vulnerabilities you'd protect against them in your application.

Correction: it is not your application but someone else's Certified Stuff (TM) that you can't change, but which is still vulnerable.

reply
upvoteby pxc2 days ago|
parent|
prev|
next
[-]
WAFs can be a useful site of intervention during incidents or when high-severity vulns are first made public. It's not a replacement for fixing the vuln, that still has to happen, but it gives you a place to mitigate it that may be faster or simpler than deploying code changes.
reply
upvoteby gopher_space2 days ago|
parent|
prev|
[-]
If your clients will let you pass the buck on security like this it would be very tempting to work towards the least onerous insurance metric and no further.
reply
upvoteby ordersofmag2 days ago|
prev|
next
[-]
A simple reason would be if you're just using it as a proxy signal for bad bots and you want to reduce the load on your real servers and let them get rejected at the CDN level. Obvious SQL injection attempt = must be malicious bot = I don't want my servers wasting their time
reply
upvoteby chrisjj1 days ago|
parent|
[-]
> A simple reason would be if you're just using it as a proxy signal for bad bots

Who would be that stupid?

reply
upvoteby benregenspan2 days ago|
prev|
next
[-]
It should be thought of as defense-in-depth only. The backend had better be immune to SQL injection, but what if someone (whether in-house or vendor) messes that up?

I do wish it were possible to write the rules in a more context-sensitive way, maybe possible with some standards around payloads (if the WAF knows that an endpoint is accepting a specific structured format, and how escapes work in that format, it could relax accordingly). But that's probably a pipe dream. Since the backend could be doing anything, paranoid rulesets have to treat even escaped data as a potential issue and it's up to users to poke holes.

reply
upvoteby nijave2 days ago|
prev|
[-]
The farther a request makes it into infrastructure, the more resources it uses.
reply