These are pretty weak arguments. Making nice graphics in games also increases frame times therefore we shouldn’t make nice graphics? Yeah wafs will slow down network requests the question is does that matter? The answer is no. The argument about cap1 is also extremely weak. It was a bad incident but it’s a single example of a waf being a vector and most of the damage was caused by IAM misconfiguration.
Discouraging the use of web application firewalls
61–70 of 145 posts
Re: Discouraging the use of web application firewalls
#62Most large companies have too many developers and too many teams to expect/assume that each team will do the right thing for security when putting something in production on the public Internet. Why? Because most software developers are bad at security (I said most not all). So yes do all the things at the bottom of this article! Teach security-by-design to all your teams. Make sure they know what OWASP is at least.…
In my experience it is that most software engineers are not incentivized to care about security.
Re: Discouraging the use of web application firewalls
#63So a WAF is something you deploy to man-in-the-middle your own traffic, but it is ok because "you kind of know the guy in the middle"? Please inspect all my HTTPS traffic, I terminated SSL, so you are free to modify the HTTP, no one will know, we trust you completely! Why is this a good idea exactly?
Re: Discouraging the use of web application firewalls
#64Earlier quoted context omitted.
I call it magic security pixie dust. You sprinkle it on top of code riddled with SQL injections nobody could be bothered to avoid or fix, and now magically the code has a become secure! You’ll find it on the shelf next to auto-scaling cloud wizardry, which can similarly be used to fix the total absence of indexes in the database.
1) WAF do far more than just prevent SQL injections. 2) Many companies don't own the software they run and so they can't guarantee that it is free of SQL injections or that the version of ORM libraries are secure. WAF protect against this. 3) Auto-scaling is just as much about high availability than performance. Database indexes do not help with the former.
There are environments where this makes sense. Banks are the classic - they have the money, they care about the risk, lots of places have systems still on java 8 and take > 1 month to deploy code fixes.
The biggest practical problem in my experience is that it's almost impossible to keep good people maintaining an enterprise WAF. Anyone with a deep enough understanding of web app security and network infra to do the job properly will get bored in the role and leave. WAFs are usually barely maintained for this reason.
Another major issue is alert handling - there's nobody with enough context. The SOC staff usually understand nothing (not the vuln, not web, not the app). The devs don't understand the vuln and the security team don't understand the app so tickets go round in circles with nobody able to understand if an alert is an FP or an actual issue. Eventually alerts start getting quietly dropped on the floor.
Re: Discouraging the use of web application firewalls
#65The author complained about the performance cost of WAFs in general, but not all WAFs have be structured like ModSecurity. They could for example be based on something like https://github.com/intel/hyperscan and perf is at a very different level.
Re: Discouraging the use of web application firewalls
#66If software development was a professional trade group, we could make membership require security training, and industry standards for ensuring security. But that'll never happen. It would mean them giving themselves more work to do, and we all know how lazy devs are.
Re: Discouraging the use of web application firewalls
#67In my group, I am considered to be the WAF SME. Enough that I wrote a training course to get into ruleset tuning.
What I see a lot is customers who are security-focused demanding "OWASP Top 10" protection and then, somehow, not understanding that it is not 10 rules you enable on the WAF. These are people often with application security and other credentials.
Most people I have seen running WAF's are in "Set it and forget it" mode. Tune the rules until it no longer blocks legitimate traffic and call it a day. I think few really understand what it is, and the why of using them.
Another funny anecdote: I had one of these customers talk about how amazing Akamai WAF was, because it never had false positives. Never? Really? That looks like a red flag to me, but they were not concerned.
Re: Discouraging the use of web application firewalls
#68Hallelujah. Also, with many single-phase apps, WAFs don't make any sense - the HTML/CSS content is just served statically, so the potential vulnerabilities are in the API, which IMO is much easier to harden. Without going into too much of a tangent, this is one reason I'm a big fan of GraphQL. It's strong typing and support for custom scalar types means malformed content gets rejected before it even gets to your code…
Re: Discouraging the use of web application firewalls
#69Earlier quoted context omitted.
> assuming the attacker bothers to spend five minutes bypassing them with one of a thousand well-known tricks I didn't realise AWS, Cloudflare etc were so incompetent that their product can be bypassed in 5 minutes. I assume you have an example of this.
Padding requests with 8k of normal looking data will bypass AWS's WAF 100% of the time according to the article. Maybe you should read it.
Re: Discouraging the use of web application firewalls
#70This sounds so much like music to my ears. Where I work a WAF is mandatory, Azure Application Gateway in our instance, and they enable ALL of the rules because the outsourced colleagues they follow the rules set by infosec like sheep. The consequences are that many requests are blocked as a false positive. Completely legitimate requests, like for instance an OpenID redirect from Azure AD (Microsoft Online) login to t…
Such a shame that you're forced to use this. We run Azure Function apps directly to public traffic and the experience is really nice & simple. Not once have I had a "I wonder if a middleman ate my request" experience. OIDC works flawlessly for us.
I would quickly grow to hate my tech stack if I had to cram stuff like AAG into it. Right now, we can spin up a very robust stack with ~3 products. The moment I have to start playing with network policies, I feel like the security level of my solution goes down not up. Manual routing, firewall or certificate management is a canary to me in 2023. I don't want to touch any of that stuff anymore - I'll probably screw it up at some point.
Perhaps you could reframe the AAG as creating an emergent situation that is less secure than the alternative without. It certainly sounds like an honest possibility based upon the workarounds you seem to be entertaining.