21–30 of 145 posts
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.
I would also say that static analysis as a panacea for SQL Injection is laughable. SAST tools have a hard time finding sql injection in code. As they quickly loose track of user controlled data. They almost always create false positives / false negatives when Parameterised queries are used incorrectly. For example when user controlled data gets into the SQL query rather than the parameter of a paremeterised query. And that completely ignores SQL Injection attacks that do not occur within your code directly, but in libraries you are using.
We all know how enterprise software vendors oversell and underdeliver. I can only imagine ITsec products in particular being even worse.
Lot of these issues could be avoided by good API design. But if you need WAF you might not be doing that... So you end up passing tokens as parameters and they end up in logs. Then again if someone has access to them they probably also have other access. But it still is often forgotten aspect.
Earlier 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..
NIST itself has been actively discouraging password rotation since 2016: https://pages.nist.gov/800-63-3/sp800-63b.html#memorizedsecr...
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…
> 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.
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…
So can IIS request filtering or whatever exists in Nagios. Right on the webserver.
Large companies have WAFPlus-as-a-service(load balancing +WAF+ SSO: any team can provision one and put their app behind a WAF. Is there any alternative to replace that?
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.
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.
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.