[HN Gopher] Discouraging the use of web application firewalls
___________________________________________________________________
Discouraging the use of web application firewalls
Author : b8
Score : 156 points
Date : 2023-11-13 20:32 UTC (2 hours ago)
(HTM) web link (www.macchaffee.com)
(TXT) w3m dump (www.macchaffee.com)
| theideaofcoffee wrote:
| 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 with risk assessors wants to be
| the first to remove them. Too much risk they say, regardless of
| how strenuously the tech component say they're unneeded.
| briffle wrote:
| 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..
| kibwen wrote:
| NIST itself has been actively discouraging password rotation
| since 2016: https://pages.nist.gov/800-63-3/sp800-63b.html#me
| morizedsecr...
| rjzzleep wrote:
| But then how will Cyberark make money?
| Arrath wrote:
| I expect you have 3M lobbying on the other side of the
| issue in the interest of post-it sales.
| rwmj wrote:
| The PCI-DSS website itself requires that you change password
| every 12 months. At the same time the period for recertifying
| PCI-DSS is ... every 12 months. I have a systematic way to
| create a new password each time, which probably isn't secure.
| jiggawatts wrote:
| 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.
| threeseed wrote:
| 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.
| SonOfLilit wrote:
| 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.
| threeseed wrote:
| > 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.
| verve_rat wrote:
| Padding requests with 8k of normal looking data will
| bypass AWS's WAF 100% of the time according to the
| article.
|
| Maybe you should read it.
| woleium wrote:
| Will it though? Maybe you should test it.
| xyzzy123 wrote:
| Look, if you want a "real" WAF capability you buy something
| like Imperva and manage the care and feeding of a team of
| say 2-4 ppl who understand web app vulnerabilities in
| depth, AND know the tool. Your SOC/NOC will need training
| and procedures too. Fully loaded an average enterprise will
| pay > $1M a year to maintain the capability if you look at
| the TCO carefully.
|
| There are environments where this makes sense. Banks are
| the classic - they have the money, they care about the
| risk, lots of places have systems still on java 8 and take
| > 1 month to deploy code fixes.
|
| The biggest practical problem in my experience is that it's
| almost impossible to keep good people maintaining an
| enterprise WAF. Anyone with a deep enough understanding of
| web app security and network infra to do the job properly
| will get bored in the role and leave. WAFs are usually
| barely maintained for this reason.
|
| Another major issue is alert handling - there's nobody with
| enough context. The SOC staff usually understand nothing
| (not the vuln, not web, not the app). The devs don't
| understand the vuln and the security team don't understand
| the app so tickets go round in circles with nobody able to
| understand if an alert is an FP or an actual issue.
| Eventually alerts start getting quietly dropped on the
| floor.
| hug wrote:
| > magically the code has a become secure!
|
| The code hasn't, but it would be a lie to say that the
| application hasn't, and as a leader of ops teams while I
| can't _directly_ influence code security & quality, I can
| damn sure influence overall security by demanding a WAF.
|
| Defense in depth is an important concept in security for a
| very good reason.
| likeclockwork wrote:
| Security isn't a property of code, it is a property of a
| system.
| xyzzy123 wrote:
| > 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.
| theideaofcoffee wrote:
| As much as I hate to admit it, I've done exactly that and
| passed the audit. Certainly says a lot about the auditors...
| ryanianian wrote:
| 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.
| SoftTalker wrote:
| 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
| department tells them.
|
| If you lie to your auditors, there's a good chance they
| won't catch it because that's not what they are looking
| for.
| xyzzy123 wrote:
| It's not a lie! The WAF is there, it's attached and it
| does absolutely nothing with unmatched performance and
| scalability. We tell the auditor this.
|
| There's no audit checkbox for "WAF actually does
| something useful", so it's fine.
| nullindividual wrote:
| In my experience with SoX, the auditors are very junior
| fresh out of college. They check boxes and move on.
| Spivak wrote:
| 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.
| xer0x wrote:
| Awesome! I feel so much better about using this to pass an
| audit.
| RexM wrote:
| Same, I was checking usernames to see if I recognized any
| as former co-workers where we had to do this.
|
| I guess there's just a decent market for the product
| everyone trying to check that box, though.
| ForkMeOnTinder wrote:
| It pairs well with the checkbox in S3 that you can tick to
| enable encryption with no other changes to your
| application.
| meepmorp wrote:
| Hey, if someone breaks into an AWS data center and steals
| some s3 drives, you're totally in the clear.
| rigelina wrote:
| You'd think that, but I had an auditor that had guidance
| requesting confirmation of security cameras on the
| servers. They wanted to drive to the AWS data center to
| see the cameras. If the drives got stolen, you'd better
| make sure AWS shares that video with you.
| RicoElectrico wrote:
| We all know how enterprise software vendors oversell and
| underdeliver. I can only imagine ITsec products in particular
| being even worse.
| Ensorceled wrote:
| Especially when you only have the product in your pipeline in
| the first place because of some security compliance checkbox
| that needs to be checked ...
| sebazzz wrote:
| Qualyss WAS - don't get me started. Generic accounts, short
| passwords you can't change, incredibly slow and not-able-to-
| debug scans. Numerous false positives. And with a crawler you
| don't truly know if you've covered everything.
| hn_throwaway_99 wrote:
| 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. For example, most
| injection attacks require the use of some "special" characters
| like < or ;, but many field types have no need to support those
| characters, so instead of just typing "strings" everywhere, you
| can have things like Email or Date or SSN or Name scalar types
| that are more restrictive in the characters they allow.
| hobs wrote:
| Pretty much every SQL injection attack is going to need to be
| injecting single quotes with some uncompliant lack of
| parameterization someone put together.
|
| Simply using parameterized queries solves this problem, no
| amount of semicolons can escape it.
| hn_throwaway_99 wrote:
| Yes, totally agree. There are many good SQL libraries now
| that used things like tagged templates (e.g. sql`SELECT *
| FROM foo WHERE bar = ${zed}`) that make it virtually
| impossible to _not_ use parametrized queries.
|
| But my primary point is that I still believe it makes sense
| to type string inputs as restrictively as possible, not just
| for SQL injections but also for other types of potential
| vulnerabilities. E.g. if you're taking a date string that you
| expect to be in YYYY-MM-DD format, it's best to type that
| string as such as furthest out as the edge as possible.
| throw555chip wrote:
| Yeah but GraphQL sucks to use as a developer.
| TurningCanadian wrote:
| only if you don't like documenting your APIs
| 1nd1ansumm3r wrote:
| 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.
| jiggawatts wrote:
| 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.
| threeseed wrote:
| 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.
| MattPalmer1086 wrote:
| Yep. If your developers actually use them consistently all
| the time. There's always someone who can't resist a bit of
| string concatenation...
| 1nd1ansumm3r wrote:
| 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.
| sbarre wrote:
| 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. Make sure you test all the things. Either own
| or rent red teams.
|
| But if you're a big enough company, you probably _also_ need
| something centralized like a WAF, because you want defense in
| depth.
|
| WAFs are far from perfect, but in my experience they are better
| than not having one in 2023.
| verve_rat wrote:
| > 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.
| amanzi wrote:
| I've fought against WAFs in the past, but in govt departments,
| they are often a check-box in your security checklist that must
| be checked. I've even had to fight a security guy telling me I
| needed two WAFs because he wasn't convinced the first WAF was
| good enough (because it was a managed service and the vendor
| didn't want to share the specific configuration.)
|
| In saying that, there are definitely use-cases where a WAF is
| required - especially if you have a legacy app on an older code-
| base that needs to be exposed to the internet.
| parl_match wrote:
| A 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
| while you have time to respond. Those rules given in the example
| are bad, for sure, and probably have false positives - but, a few
| days of a slightly higher rate of false positives while you patch
| is probably worth it to most organizations.
|
| Lastly, WAFs let you increase "risk scores" of requests and IPs,
| which lets you turn up captchas and other roadblocks against
| malicious IPs. This raises the bar from the floor to somewhere
| about knee height. Not a lot, but one more thing for an attacker
| to have to step over.
|
| I do agree, though, that people treat WAFs as a magic solution or
| make them really heavy. Against application attacks, I view them
| as a tool of medium importance. Also, there are also better and
| worse vendors out there. Personally, in a WAF, I view "less as
| more".
|
| The more rules and complexity, the more problems you're going to
| have. Adding rules should be temporary, and there's very few
| reasons to have blocking rulesets for long running issues.
| macNchz wrote:
| > people treat WAFs as a magic solution
|
| I think ultimately acknowledging that there are no magic
| solutions, only a variety of options that can each contribute
| to reducing the probability of something bad happening, is
| critical to approaching security issues effectively.
|
| My first experience with WAFs was part of a check-the-box
| security/compliance process, and I thought they were dumb. Easy
| to work around! Just regexes! With time I've come to appreciate
| that they're pretty low effort to operate, can be fairly
| lightweight, and wind up being one more thing for an attacker
| to deal with, in a world where each thing they have to deal
| with decreases their chances of success and increases the
| chance of someone noticing.
|
| If we assume that basically everything can be bypassed by a
| sufficiently motivated attacker, the best approach is defense-
| in-depth where there are multiple barriers they need to
| traverse, and little opportunity to do so "quietly". WAFs can
| be evaded with clever approaches, sure, but getting to that
| point means they initially triggered a block, and have to make
| additional requests to test their evasion payload, each of
| which increases the signal we have to block more aggressively,
| trigger an alarm, and get a human involved.
| sebazzz wrote:
| This sounds so much like music to my ears. Where I work a WAF is
| mandatory, Azure Application Gateway in our instance, and they
| enable ALL of the rules because the outsourced colleagues they
| follow the rules set by infosec like sheep. The consequences are
| that many requests are blocked as a false positive.
|
| Completely legitimate requests, like for instance an OpenID
| redirect from Azure AD (Microsoft Online) login to the
| application. They then get blocked by the SQL Injection rules in
| AAG. So user friendly.
|
| At one point we were seriously considering base64 encoding all
| request bodies from javascript before sending them to the server
| and decoding them there - just to get around this bullshit.
| bob1029 wrote:
| > Azure Application Gateway
|
| Such a shame that you're forced to use this. We run Azure
| Function apps directly to public traffic and the experience is
| really nice & simple. Not once have I had a "I wonder if a
| middleman ate my request" experience. OIDC works flawlessly for
| us.
|
| I would quickly grow to hate my tech stack if I had to cram
| stuff like AAG into it. Right now, we can spin up a very robust
| stack with ~3 products. The moment I have to start playing with
| network policies, I feel like the security level of my solution
| goes _down_ not up. Manual routing, firewall or certificate
| management is a canary to me in 2023. I don 't want to touch
| any of that stuff anymore - I'll probably screw it up at some
| point.
|
| Perhaps you could reframe the AAG as creating an emergent
| situation that is less secure than the alternative without. It
| certainly sounds like an honest possibility based upon the
| workarounds you seem to be entertaining.
| raincom wrote:
| 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?
| jauntywundrkind wrote:
| It'd be neat to see something like Kubernetes SPIFFE for
| identity/sso combined with something like Kubernetes Gateway
| API for front-end routing.
| sebazzz wrote:
| > 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...
| doublerabbit wrote:
| What about Ket? In this day and age whisky just isn't cutting
| it.
| asylteltine wrote:
| These are pretty weak arguments. Making nice graphics in games
| also increases frame times therefore we shouldn't make nice
| graphics? Yeah wafs will slow down network requests the question
| is _does that matter?_
|
| 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.
| hotnfresh wrote:
| The WAF increasing hypothetical attack surface was the closest
| thing to a good argument on there, and since their
| "alternatives" amounted to "don't misconfigure anything or
| deploy a vulnerability", which solution would also have solved
| their single example of WAF-as-an-attack-vector actually
| happening... yeah, that still made the piece less convincing,
| overall.
| JoeSpaghettio wrote:
| 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 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.
| sebazzz wrote:
| > 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.
| JoeSpaghettio wrote:
| 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.
| threeseed wrote:
| Many applications these days don't have web servers in front
| of them.
| Ekaros wrote:
| WAFs are also bring on risks that are not considered. At least in
| scenarios where things get logged and no one considers how they
| are sanitized. And then there is also GDPR in Europe.
|
| 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.
| c0balt wrote:
| WAFs are a good way of masking some issues but they tend to not
| help against more sophisticated attackers, as in a bit more
| sophisticated than just using metasploit.
| vasdae wrote:
| I work with PHP and I think WAFs are potentially useful (and
| potentially problematic).
| zsoltkacsandi wrote:
| 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.
| ppierald wrote:
| A few points.
|
| PCI-DSS does not mandate the use of a WAF. It is one of two ways
| you can fulfill requirement 6.5 or 6.6. WAF + OWASP Top Ten
| ruleset is typically easier to get evidence for your auditor, but
| you can show that continuous scanning using a DAST scanning
| engine to meet requirements.
|
| I would have a WAF installed with very few highly tuned rules
| against mostly SQLi. Why? Because the damage of letting that
| through and praying that the developer or web-app framework does
| it right are significant. The rules for SQLi are pretty easy to
| get right and dropping that traffic before it gets to your web
| server is a reasonable thing.
|
| I would have a WAF installed with no rules too. It is nice to
| have something there where you can drop in a Log4J rule and get
| protection relatively quickly for attacks of that nature. There
| have been a number of these over the years and a small
| performance penalty seems worth the big picture safety net.
|
| I am against the pricey models that the cloud vendors push. WAF
| can get expensive. They typically are bundled with other cloud
| services, but hey, if you've gotten that far, you are probably
| outsourcing most things to the cloud provider anyway.
|
| I do not like WAF pragmatically because it lets the developer off
| the hook in many ways. There is something there doing their work
| for them and another reason for some developers to not understand
| or care about the security of their applications. Something else
| will do it for me whether I know this or not.
| hermannj314 wrote:
| So a WAF is something you deploy to man-in-the-middle your own
| traffic, but it is ok because "you kind of know the guy in the
| middle"?
|
| Please inspect all my HTTPS traffic, I terminated SSL, so you are
| free to modify the HTTP, no one will know, we trust you
| completely!
|
| Why is this a good idea exactly?
| hotnfresh wrote:
| Basically every service of any size is terminating SSL before
| the request gets to the "real" recipient, anyway. They'd do it
| with or without a WAF. CDN, load-balancing, centralized
| routing, you're doing it _somewhere_ whether or not a WAF is
| involved.
| KronisLV wrote:
| There was a point in the article about WAFs being quite slow, in
| particular the article talks about Nginx with ModSecurity.
|
| However, some benchmarks from _a while ago_ suggested that Nginx
| performs worse with ModSecurity than Apache does in a similar
| configuration:
| https://blog.litespeedtech.com/2019/12/02/modsecurity-perfor...
|
| Seems like Coraza also has some more recent benchmarks, since
| from what I can tell they more or less aim to replace ModSecurity
| in some regards: https://coraza.io/docs/reference/benchmarks/
|
| I wonder whether anyone has undertaken the effort to compare the
| performance of the self-hosted WAF options in 2023, or at least
| in the past few years.
|
| Personally, I think the performance tradeoff might sometimes be
| worth it if security does indeed improve, the Swiss cheese model
| (defense in depth) and all that:
| https://en.wikipedia.org/wiki/Swiss_cheese_model
| tehalex wrote:
| Agree for our apps.
|
| However, for 3rd party code we run/host but don't really own I
| see value to a WAF. For example, we unfortunately run WordPress,
| and I don't have time to manually audit all of the stupid plugins
| people want to be installed beyond a checker for known
| vulnerabilities, so a WAF is some comfort/protection.
| thestepafter wrote:
| Agreed on the 3rd party code having a WAF.
|
| What WAF solution are you using for WordPress?
| joshchaney wrote:
| I think WAF is really a bigger set of tools now (bot protection,
| IP reputation, L7 DDoS/rate limiting, API restrictions) than just
| signatures. Virtual patching is also incredibly important and
| there's really no other security tool that gives you the
| granularity to restrict something like the values of some param
| on a specific path of your app, but only when some cookie exists.
|
| I don't think the performance concerns here are accurate. I think
| these days most people are using vendors own cloud infra (Akamai,
| Cloudflare, F5, Imperva, etc), but even if you are using WAF on-
| prem, F5 and Imperva sell purpose built hardware that have no
| problem handling tons of requests. Most WAF's also have weighted
| signatures these days and won't just fire on ${jndi. "${jndi"
| might give 5pts, while "org.apache.*" gives another 5, and maybe
| their threshold is set for 10 for blocking.
|
| I have plenty of issues with WAF's and I would invest a lot more
| in developer training, but I think they still have their place.
| allanrbo wrote:
| I think of WAFs as an extra safety net. Defense in depth.
|
| The author complained about the performance cost of WAFs in
| general, but not all WAFs have be structured like ModSecurity.
| They could for example be based on something like
| https://github.com/intel/hyperscan and perf is at a very
| different level.
| VWWHFSfQ wrote:
| Or even do what what CloudFlare did [1] and transpile all the
| slow ModSecurity rules to Lua and deploy OpenResty at the edge.
| Run them in nginx+luajit.
|
| [1] https://blog.cloudflare.com/cloudflares-new-waf-compiling-
| to...
| throwawaaarrgh wrote:
| Show me an alternative that I can deploy despite developers
| having both the lack of knowledge and complete indifference of
| security. They don't care and they aren't forced to conform to
| any security standards, so a WAF is literally the only thing I
| can do to try to improve things. I can't rewrite all their code
| for them. Management hears about a WAF and makes that a
| requirement and moves on.
|
| If software development was a professional trade group, we could
| make membership require security training, and industry standards
| for ensuring security. But that'll never happen. It would mean
| them giving themselves more work to do, and we all know how lazy
| devs are.
| Cpoll wrote:
| > Management hears about a WAF and makes that a requirement and
| moves on.
|
| In this case, a WAF is giving the illusion of safety. So I feel
| like you're actually making an argument against WAFs.
| RajT88 wrote:
| 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 with application security and other credentials.
|
| Most people I have seen running WAF's are in "Set it and forget
| it" mode. Tune the rules until it no longer blocks legitimate
| traffic and call it a day. I think few really understand what it
| is, and the why of using them.
|
| Another funny anecdote: I had one of these customers talk about
| how amazing Akamai WAF was, because it never had false positives.
| Never? Really? That looks like a red flag to me, but they were
| not concerned.
| ThomasBb wrote:
| Feels like you could replace WAF with DLP, EDR or most any other
| 3 letter abbreviation... Or indeed bike helmets. Vendor push +
| industry 'best practice' tribal knowledge is tough to resist.
| lemmsjid wrote:
| To me this blog post doesn't fully make its case, though has many
| good points and is a good read.
|
| I think my main logical objection is that the alternative best
| practices at the end of the article were all security best
| practices before WAFs existed. Which makes me ask the question,
| why did WAFs come into existence in the first place? Did the
| founders of those companies convince customers they needed them
| without those customers actually need them?
|
| I think not. In the years before WAFs existed, I was in the
| position more than once of being in an organization whose web
| application security footprint had grown to the point where we
| ended up writing a home-grown version of a WAF. E.g. adding an
| interception layer that would analyze inputs and outputs for
| typical security violations.
|
| Why? Well, first because it started to give us a sense of the
| types of attacks that people were trying to use. Second, because
| the types of mitigations mentioned by the author of this blog
| post aren't the whole story. You can audit that your entire
| system avoids SQL injection attacks via stored procedures, then
| your company buys another company with a code base that fails
| such audits. Or someone attacks by leveraging your caching layer
| which stores and sends back unaudited key-value pairs. Perhaps
| (this has happened to me) a bug gets introduced into the
| deployment system, and the code that forces authentication is not
| shipped, and the calling code doesn't properly fail when the auth
| checking code isn't in there. A real head slapper in hindsight.
|
| I do like the best practice of process isolation around APIs, and
| only allowing APIs to have the privileges they require, but in
| practice, if there are hundreds of APIs undergoing frequent
| changes, the complexity of managing that becomes a security risk
| in and of itself, because the ACL rules are deeply complicated.
|
| Relying solely on a WAF seems like a bad practice. But also
| relying only on secure design philosophy is a practice with
| plenty of historical failures.
|
| So if the point of the article is that WAFs breed complacency, I
| agree with that! But if a WAF is used as an analysis, auditing,
| and fast-response layer, alongside following secure design
| principles, then I'd say that based on personal experience, if
| WAFs didn't exist, people would write home grown ones with their
| own sets of flaws.
| kabigon wrote:
| I get it and the points made here are valid but, the reality is
| that the teams deploying the WAF + infra and the team writing the
| insecure/secure code are different teams with different roadmaps.
| We have to deploy a WAF because the developers are not writing
| this magical unicorn code that follows all security best
| practices and gets refactored once a week. There are
| vulnerabilities, issues etc. that need to be addressed just like
| any app. SO yes, WAF is necessary.
| rickreynoldssf wrote:
| A simple "WAF" can be implemented without hardware or anything
| overly complex by doing just a three things that will eliminate
| most malicious traffic.
|
| * Block all traffic from AWS, Azure, etc. yeah, you'll loose some
| traffic from some VPNs and maybe you care and if so, this
| suggestion isn't for you.
|
| * Verify the traffic saying it's GoogleBot, BingBot or DuckBot
| are really from those sources. All three provide a list of valid
| IPs accessible via a REST endpoint to match incoming IPs against.
| Block Yandex etc. There is likely no good for you coming from a
| Russian or Chinese search engine indexing you.
|
| * Make sure the browser versions in the User Agent aren't like 5
| years old. That's a great indicator of a bot.
___________________________________________________________________
(page generated 2023-11-13 23:00 UTC)