Live data from Hacker News

Discouraging the use of web application firewalls

macchaffee.com

61–70 of 145 posts

Re: Discouraging the use of web application firewalls

#61

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.

The WAF increasing hypothetical attack surface was the closest thing to a good argument on there, and since their “alternatives” amounted to “don’t misconfigure anything or deploy a vulnerability”, which solution would also have solved their single example of WAF-as-an-attack-vector actually happening… yeah, that still made the piece less convincing, overall.

Re: Discouraging the use of web application firewalls

#62
post #10

Most 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.…

> Why? Because most software developers are bad at security (I said most not all).

In my experience it is that most software engineers are not incentivized to care about security.

Re: Discouraging the use of web application firewalls

#63

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

Basically every service of any size is terminating SSL before the request gets to the “real” recipient, anyway. They’d do it with or without a WAF. CDN, load-balancing, centralized routing, you’re doing it somewhere whether or not a WAF is involved.

Re: Discouraging the use of web application firewalls

#64

Earlier 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.

Look, if you want a "real" WAF capability you buy something like Imperva and manage the care and feeding of a team of say 2-4 ppl who understand web app vulnerabilities in depth, AND know the tool. Your SOC/NOC will need training and procedures too. Fully loaded an average enterprise will pay > $1M a year to maintain the capability if you look at the TCO carefully.

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

#65
I think of WAFs as an extra safety net. Defense in depth.

The 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

#66
Show me an alternative that I can deploy despite developers having both the lack of knowledge and complete indifference of security. They don't care and they aren't forced to conform to any security standards, so a WAF is literally the only thing I can do to try to improve things. I can't rewrite all their code for them. Management hears about a WAF and makes that a requirement and moves on.

If 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

#67
I cannot argue with this too much. A WAF will protect you from unsophisticated attackers - at great cost.

In 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

#68

Hallelujah. 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…

Yeah but GraphQL sucks to use as a developer.

Re: Discouraging the use of web application firewalls

#69

Earlier 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.

Will it though? Maybe you should test it.

Re: Discouraging the use of web application firewalls

#70
post #16

This 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…

> Azure Application Gateway

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.

Post reply on HN