131–140 of 145 posts
Earlier quoted context omitted.
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.
Despite all of that we just found a SQL injection that existed for years somehow. Luckily the WAF blocked attempts to exploit it until we could issue a fix.
Defence in depth is the win here.
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…
The article notes the problem of the attack surface of WAF products themselves, and raises questions about the security posture of the products and the vendors. Compliance standards need to address the risks and weigh them against the benefits of WAFs. If, as the author argues, they have reached a point where they do more harm than good, the compliance bodies need to be honest about that and reevaluate recommendation…
Earlier quoted context omitted.
NIST itself has been actively discouraging password rotation since 2016: https://pages.nist.gov/800-63-3/sp800-63b.html#memorizedsecr...
NIST discourages it, but most of the US government still requires it. In fact, I used to have a 60-day password rotation policy with such brilliant requirements as "no more than three characters of one class sequentially." I soon realised that "ShitFuck!", thus, was a valid password -- and off I went. Meanwhile, a teammate who had previously been a technical writer contracting with the NSA told of the "waterfall meth…
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…
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..
Writing all of this and concluding with a recommendation to use static analyzers feels like a joke. So we shouldn't use a tool that scans for known bad vectors but use a tool that...scans for known bad vectors instead? Yeah, sure.
Earlier quoted context omitted.
I did not downvote you, but as the article explains, WAFs don't protect against anything assuming the attacker bothers to spend five minutes bypassing them with one of a thousand well-known tricks.
> 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.
This guide, linked from the article, shows some simple evergreen bypass techniques (section "WAF bypass cheat sheet"):
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 wi…
> Now I'll admit these ideas are quite broad Ayup. Especially for small teams working with large piles of software (lookin' at you WordPress) that are insecure out of the box. The ideas are also constrained mainly to fixing SQL injections, which are only an aspect of security. * Isolate components in case of a breach That's great but it doesn't fix a breach, it just limits the scope. Better than nothing but if a WAF…
> Do any of these help against a DDOS, or even accidental DOS caused by search spam? Nah, but a WAF at the edge stops the latter in its tracks. Only if the WAF can reject bad requests more cheaply than the thing behind it. IME if your app is implemented decently it will outperform the WAF.
Earlier quoted context omitted.
The article notes the problem of the attack surface of WAF products themselves, and raises questions about the security posture of the products and the vendors. Compliance standards need to address the risks and weigh them against the benefits of WAFs. If, as the author argues, they have reached a point where they do more harm than good, the compliance bodies need to be honest about that and reevaluate recommendation…
Here is a big lesson that I "learned": actual security does not matter for the purpose of avoiding risks and fines. What matters is the ability to say "we got hacked despite following the accepted best practice" or "we can shift the blame HERE". Having a paid-for WAF ticks both boxes.
What matters, of course, is money.
Only if the WAFs themselves become a significant attack vector, to the extent where blame for breaches affects the bottom lines of the WAF vendors, the situation will start to change.
Earlier quoted context omitted.
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.
Let me rephrase: software development (the action of engineers and the whole process in general) is actively insensitvised to not care about security. The consequences of poor security are often way, way lower than the costs of doing it properly. Add on to that, that security problems are contingent risks that only "pay out" in a small number of cases and you have a recipe for low expected value for investment into s…
There's certainly a trope among developers that "the business" doesn't give us time to do work properly, including security.. and that's it's just "ship features fast"..
My take on this is that it's on us, as professional developers and particularly technical leaders, to force that issue and advocate for better practices.
I've advocated for better technical practices at several jobs I've been at, and in many cases there was no intentional desire to incentivize bad practices, it was simply that the leaders weren't aware of all the requirements, and of the consequences of cutting too many corners.
When framed in the context of business value and risk, it's not as hard as you think to introduce better standards to most software development teams. Smart leaders are open to listening and changing if it means better outcomes.
That said, if your technical leadership isn't interested in supporting this kind of improvement or helping you advocate, then maybe it's time to dust off the CV if you personally care about it.