Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Discouraging the use of web application firewalls

macchaffee.com

Post reply on HN
Print view View original

31–40 of 145 posts

Re: Discouraging the use of web application firewalls

#31

Post by JoeSpaghettio »

sebazzz wrote: post #27
JoeSpaghettio wrote: post #22

So there are a few issues with this, WAFs do have their uses, generally speaking yes rules based on regexes looking for sql injection are silly. But they do have their useses. For example tarrgeted blocking, https://confluence.atlassian.com/security/cve-2023-22515-pri... . While waiting for the patch, a WAF can quickly block all requests to the /setup endpoint. I would also say that static analysis as a panacea for S…

> While waiting for the patch, a WAF can quickly block all requests to the /setup endpoint. So can IIS request filtering or whatever exists in Nagios. Right on the webserver.

depends on the org. The appsec team, may not have access to the webserver in production atleast not quickly. But will have access to modify a WAF they own.

Re: Discouraging the use of web application firewalls

#32

Post by MattPalmer1086 »

jiggawatts wrote: post #12
1nd1ansumm3r wrote: post #8

Nicely written and the author clearly has more experience than myself. I did, however, get hit with a data breach via SQL injection, and everyone I spoke to (not vendors or sales folks) seemed to agree that a WAF would have blocked the attack outright.

Parameterised SQL queries would have blocked it outright also. Parameterised queries however don’t need an annual fee and a team of security engineers to babysit it.

Yep. If your developers actually use them consistently all the time. There's always someone who can't resist a bit of string concatenation...

Re: Discouraging the use of web application firewalls

#34

Post by doublerabbit »

sebazzz wrote: post #20

> Imagine how slow the web would be if every piece of JavaScript needed to be analyzed by hundreds of regexes before being executed! Well, there is super duper secure mode in Edge that disables the JIT - so there's that. It also enables CET. https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...

What about Ket? In this day and age whisky just isn't cutting it.

Re: Discouraging the use of web application firewalls

#35

Post by threeseed »

jiggawatts wrote: post #9
theideaofcoffee wrote: post #2

People will stop deploying WAFs when the compliance standards are rewritten to not require them. They are prominent in lots of installations because the box ticking exercise of compliance frameworks, namely PCI or HIPAA, require a WAF-like component to reach compliance. It took long enough for them to be written in that now everyone knows they need one. It will be even longer for them to be phased out, and no one wit…

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.

Re: Discouraging the use of web application firewalls

#36

Post by 1nd1ansumm3r »

jiggawatts wrote: post #12
1nd1ansumm3r wrote: post #8

Nicely written and the author clearly has more experience than myself. I did, however, get hit with a data breach via SQL injection, and everyone I spoke to (not vendors or sales folks) seemed to agree that a WAF would have blocked the attack outright.

Parameterised SQL queries would have blocked it outright also. Parameterised queries however don’t need an annual fee and a team of security engineers to babysit it.

Sometimes one has to host an application and has no control over the details of how that application is developed or configured related to parameterized SQL queries.

Re: Discouraging the use of web application firewalls

#37

Post by ForkMeOnTinder »

Spivak wrote: post #26
xyzzy123 wrote: post #14

Earlier quoted context omitted.

> People will stop deploying WAFs when the compliance standards are rewritten to not require them. Honestly AWS WAF is perfect for this. It's not a great WAF but it is ideal if you need "pretend to have a WAF" as a service so you can tick the box.

It's gotta be my favorite AWS service for this reason alone. It's almost useless but that's a feature not a bug. They knew exactly their market.

It pairs well with the checkbox in S3 that you can tick to enable encryption with no other changes to your application.

Re: Discouraging the use of web application firewalls

#38

Post by threeseed »

sebazzz wrote: post #27
JoeSpaghettio wrote: post #22

So there are a few issues with this, WAFs do have their uses, generally speaking yes rules based on regexes looking for sql injection are silly. But they do have their useses. For example tarrgeted blocking, https://confluence.atlassian.com/security/cve-2023-22515-pri... . While waiting for the patch, a WAF can quickly block all requests to the /setup endpoint. I would also say that static analysis as a panacea for S…

> While waiting for the patch, a WAF can quickly block all requests to the /setup endpoint. So can IIS request filtering or whatever exists in Nagios. Right on the webserver.

Many applications these days don't have web servers in front of them.

Re: Discouraging the use of web application firewalls

#40

Post by zsoltkacsandi »

Here is my opinion: WAF is a tool, use it where it makes sense. Don’t use it where it doesn’t make sense.

I’ve seen many use cases where deploying a WAF solution was completely reasonable and the problem couldn’t have been solved in the application code. And let’s not forget often you have to run applications that were written by other companies, and you still need an additional layer of security.

—-

These “stop using X” articles are really pointless (and boring). They also misguide the people who have less experience in a particular field.

Post reply on HN