Live data from Hacker News

Discouraging the use of web application firewalls

macchaffee.com

91–100 of 145 posts

Re: Discouraging the use of web application firewalls

#92

Earlier quoted context omitted.

It's basically fizzbuzz. If you have a WAF, it proves you know how to add a WAF. Presumably even one you know how to configure when security needs change. Compliance auditors are mostly there to underwrite posture, not actual risk.

Auditors pretty much only certify that you have told them you are doing what you are supposed to be doing. They are not logging in to your servers and verifying that an AWF is running in front of your web server. They are not probing your network from the outside to see if an AWF is blocking their activity. Just as financial auditors are only confirming that your financial statements match what your accounting depart…

You can lie to these auditors, but you can't lie to pentesters. These people on the other hand are designed to probe your network from the outside.

Re: Discouraging the use of web application firewalls

#93

Earlier quoted context omitted.

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.

WAF don't require a team of security engineers to babysit. Cloudflare, AWS, GCP etc offerings are basically just one click and for smaller sites will be free. And over the years there have been many security flaws in how SQL libraries actually handle parameterisation.

That "one click" instantly broke every single application I've seen it applied to.

Eliminating false positives is a significant effort.

Re: Discouraging the use of web application firewalls

#94

Earlier quoted context omitted.

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

This is what code reviews are for.

Re: Discouraging the use of web application firewalls

#95

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.

As much as I hate to admit it, I've done exactly that and passed the audit. Certainly says a lot about the auditors...

> Certainly says a lot about the auditors...

Security auditors are (quite literally) accountants.

Re: Discouraging the use of web application firewalls

#96
This is like saying "Don't have a network-based firewall, because Google figured out zero-trust".

There are absolutely ways to do things that we should look to for inspiration, but the harsh reality is that legacy software, legacy teams and regulations mean we must (and often should) continue using security-team-maintained chokepoints for Internet-exposed services.

If there were to become some standard API gateway tool that is clearly auditable, with obvious IAM/permissions to specific database sections for each API call, then maybe that could be used in lieu of a WAF. The point is, regulators and Infosec need to have a tool or process in-line (physically, like a WAF or firewall) or procedurally (such as analysis and checkpoints in a CI deployment) to ensure a business application is secure.

Re: Discouraging the use of web application firewalls

#97
I've found that the most effective way to secure a webserver is to just block any IP that pounds on the default vhost by IP. No WAF, no fuss.

After a few months of building up a denylist, I get almost zero hits from scanners and spambots.

https://gist.github.com/noahbailey/474922b752ee733d639c91e27...

https://nbailey.ca/post/block-scanners/

Re: Discouraging the use of web application firewalls

#99

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…

All of that is possible with plain old REST APIs as well. For example, FastAPI and pydantic will do this sort of parsing and validating at the application edge.

Re: Discouraging the use of web application firewalls

#100
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.

This is my personal opinion but any developer building software that runs on the public Internet should not need to be incentivized to care about security.

It's a fundamental part of the job.

Post reply on HN