Earlier quoted context omitted.
> 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.
Discouraging the use of web application firewalls
141–145 of 145 posts
Re: Discouraging the use of web application firewalls
#142A few counters to this: First off, most large applications need something on the edge to help deal with volumetric attacks. If you've already got something there, adding a light WAF engine isn't exactly a huge ask. It's (almost) free. Also, WAFs let you "fast patch" against vulnerabilities. The Log4j example the author gives as a negative is actually a positive. Your vendor can help prevent you from being attacked wh…
We use AWS WAF for a bunch of this which is necessary because the other AWS components are so dumb. We definitely don't want to overcomplicate our WAF setup. Good enough is good enough.
Re: Discouraging the use of web application firewalls
#143Earlier quoted context omitted.
We are still waiting on compliance standards to update their password change policies to reflect what most people have been saying for over a decade, that frequently changing passwords are a security risk..
Got into a quarrel about this with our IT director at a previous company. I wish there was a security best practices FAQ I could link to for this sort of stuff.
https://pages.nist.gov/800-63-3/sp800-63b.html#memorizedsecr...
Re: Discouraging the use of web application firewalls
#144Earlier quoted context omitted.
Do you really think that the former CEO of AWS is not referring to the addressable market for cloud?
What does that have to do with public facing services? Stop, read, and think before ratcheting up the rudeness.
Re: Discouraging the use of web application firewalls
#145Weeks later, they got back to me. It turned out the payment processor's WAF was rejecting my submission because the street name contained the word "Union", and the WAF was sanitizing input fields by rejecting any SQL syntax, despite the lack of control sequences. Napkin math suggests their WAF would reject payments from 1% of the US population on the basis of their street or city name. This is a hidden tax on top of their nominal processing fees!
Best practice also means the WAF is probably also configured to accept vendor security updates, silently introducing even more rejection criteria.
The love of compliance is the root of many types of evil.