Cloudflare's and all other "Webapp Firewalls" are just snake oil. They can't know what transformations are done server-side on untrusted input, so you'll always (with enough time and determination) be able to craft a string that passes the WAF but exploits the backend.
Well it depends, the WAF has multiple levels of strictness that will break origins if too strict. If an origin can tolerate the more strict levels, then it would be hard to bypass.
I agree with you, in most cases, but unfortunately in some regulated industries, more and more auditors are putting WAFs as a requirement for secure architectures. No amount of explaining why it doesn't make sense changes anything, as the auditors rarely understand why they're asking for WAFs - they just need to check the box.
There are occasions though where WAFs can be somewhat useful, like where you need to secure a vendors webapp that you can't patch without them releasing a fix or trust, but for legacy or business reasons are required to run.
So some of us are forced to buy and implement these products regardless of effectiveness, and it is helpful to see how vendors respond I think.
I call this CYA (cover your ass) security. Passing blame for failures is more important than the technical merits of the product. If it fails you say "see ya" to the current vendor and hire a new whipping boy. Lol.
(I work at Cloudflare and manage the Product Security team, so...disclaimer).
WAFs definitely help. No WAF is perfect, but having an additional layer to make exploitation harder, and having a tool designed to block specific attacks (like when a new CVE is issued for a CMS) is powerful.
Not to mention that WAFs are a requirement in regulated industries. PCI mandates it. And your SOC2 + ISO auditors probably will ask about it too.
having worked on, well, quite literally the other side of the room as the parent, i'll echo this and add a bit: WAFs are not perfect, WAFs are not themselves defense in depth, and WAFs are--most importantly--one facet in a complex set of tools that users find difficult to understand. Industry has perhaps come a long way in usable end-user browser security (hell yeah https://twitter.com/__apf__/), but it has a long way to go still end-user server security usability.
the major challenges i've seen with WAFs on that front are that users treat them (and often, any part of a security solution) as a panacea for general classes of problems, which they aren't. WAFs can provide excellent targeted defense ("this request looks like it's trying to exploit CVE-2020-4521 specifically, I should almost certainly block it") and very mediocre general defense ("this request kinda looks like it might be SQLi--block it?").
the latter suffers from the issues others have raised in adjacent comments: the WAF doesn't know if the defended application applies its own sanitization (it should, but for its function, the WAF assumes that upstream doesn't, and could be vulnerable) and/or if the request content is something that reasonably should include SQLi-like content. The Cloudflare WAF in particular, at least circa 2018, suffered from including a lot of OWASP project rules that could spot "naked" SQLi quite easily, but in doing so also triggered on a lot content where the appearance of SQLi was, in fact, normal usage of punctuation characters where they made sense in plain English prose--someone can and should legitimately use quotation marks in the course of writing a prose English comment, like I'm doing right now, along with an occasional semicolon or paren alongside quotes, because those same symbols have meaning and use in both SQL and English prose.
this leads to lots of fun user confusion scenarios, where someone on the sales side of thing says "yes! enable the WAF! more protection = more product value for you!", and some months after, someone on the support side says "sorry, but the WAF can also generate false positives on legit text content, or can miss legit malicious content if it's gift-wrapped effectively (a la the OP)".
that sort of nuance is really hard to understand for more naive users, who can't easily distinguish between "the WAF blocks things it can positively ID as threats", "the WAF blocks things it mistakenly identifies as a threat based on superficial similarity to actual threats", and "the WAF doesn't block things that are threats, but are crafted to avoid the WAF". Users just see ~WAF~, and unfortunately often see it as technological wizardry that does or should just work, because it's magic. It ain't, but communicating the nuances, to a general audience? That's damn hard, and has long been neglected across industry because it doesn't fit well into shiny marketing copy.
technical improvements are valuable, but they can only go so far--at some point, there's greater value in educational content that helps dispel the magic somewhat, so that users understand the shortcomings of any given tool and can spot when those shortcomings arise. Thankfully the whole Cloudflare TV project and other educational content does seem to be progressing, though im unfortunately too far removed from the day to day now to see how well it's succeeding :) optimism hat on, it is, and godspeed!
SQL injection can be as easy as accepting only quoted strings as parameters, with the parameter text not allowed to contain unescaped quotes itself, and converting strings to numbers and dates with SQL conversion funcs (wouldn't work with MySQL syntax though), or in fact using prepared statements. No need for heuristic best-efforts approaches.
As others have said, there are plenty of useful aspects to WAF technology. For my organization in particular, we have a lot of legacy junk floating around, and the WAF is an easy way to add a layer of protection to stuff nobody is working on anymore (keeping internet-facing systems up to date is another convo). As part of that legacy conversation, in addition to prevention of injection and other common web attacks, you get the added benefit of being able to add headers and upgrade TLS connections for old stuff to keep those pesky security scorecard reports off the CISOs desk. For most managed solutions, you can implement geo-blocking with a couple clicks. For the most part, a WAF is good for driveby stuff and zero-days. You have to look at it as just another part of a defense-in-depth strategy, and like any other control, if you put all your eggs in one basket it'll be a bad day. Definitely not snake-oil though.
WAFs sound pretty darn good for simple, well-understood services with known good inputs. If every valid request to some half-forgotten Perl remnant in /cgi-bin looks like "path\?id=[0-9]{1,10}" then let that allow rule rip!
You have to understand the human element. In any big organization, you have many teams with varying security practices working on systems.
It's simply impossible to consistently recruit developers with good security knowledge, especially if we want, as an industry, to take responsibility for getting new developers up the first few rungs of the ladder.
And you do need a mechanism that can provide defense for legacy applications, or to quickly mitigate 0-days.
As long as we can't guarantee that developers won't screw up, we need tools for cyber-security to mitigate these attacks. WAFs and other layered security devices do fill that need.
However!
Any layered security device must be bypassable. Your WAF is probably configured by the same people who make the automated security tests your pen-testers run.
If your pen-testers aren't bypassing layered security and attacking your application directly, then you're not really doing layered security anymore. Your WAF's security becomes snake oil, and your application's security is untested.
That’s security hand wavy drama. By that standard why set a password, they are all crackable after all! The reality is that most attacks are automated kits or similar stuff that WAF combined with other controls can help with. It’s risk mitigation.
At the end of the day, the red team always wins. Tactical risk mitigation, segmentation and logging are the way to address security. Best case, your monitoring detects and alerts on the guy attacking the WAF, otherwise you have logs to conduct an investigation later.
Cloudflare's bug bounty program used to be exclusively T-Shirts/swag but it looks like they now might give out service credits, it doesn't state the exact reward:
> Reporters under the age of 18 will not be eligible to receive Cloudflare service rewards
>Cloudflare runs a private bug bounty program. If you submit a valid report on bounty-eligible assets through our disclosure program, we will transfer your report to our bug bounty program and invite you as a participant.
So...if I naively parameterize the inputs for my queries (select blah, blah, blah FROM customers WHERE id LIKE @id) and have the incoming request just check for an id parameter and make a SQL parameter named @id, with value = whatever the input is, am I 90% there?
Or are there still vulns/exploits for that kind of usage?
I am not sure if parametrized statements solve 100% of your SQLi problems, but I know they at least offer basic protection. I have to study them in order to give you a complete answer, but I found this https://stackoverflow.com/questions/6786034/can-parameterize...
Another safety measure worth looking at is always enforcing types for params before using them for anything. So if id is an int parse it to an int first. That way you know no extra data/commands can be in the param.
You don't need to, though, that's what parameterized queries are for. I'd argue that providing out-of-bounds checks like that will increase the likelihood of someone relying on them down the road.
The boundary for variable parsing should be the edge of your application. Otherwise you can't be sure that your validity checks (for example) are doing what you think they are, or that your sql is doing what you think it is.
As one example of this consider the rails vuln CVE-2013-0156. Lax param parsing and cleaning (or none), can lead to problems like this and even sqli if you meant to accept a string and instead accept something like an array or a symbol.
I'm terms of injection you're 100% there. Parameterised queries are safe (unless there's a bug in the database itself).
It doesn't mean you're safe in other contexts though. For example if you allow reading another user's data without checking permissions, you've got an IDOR vulnerability. https://portswigger.net/web-security/access-control/idor
You can go further by actually validating types (e.g. “id should be a number between 1 and 20 digits”) but I'd class that more as general input validation since you want to do that everywhere even if you don't have SQL database.
I wonder if the fix for this was just adding some more RegEx to the WAF and calling it patched.
To me, it seems like it's not possible for a WAF to honestly promise "SQL Injection Prevention," because it's surely just string matching and not actually building an AST/simulating a database query before passing the HTTP query along to the application server. The WAF can't possibly know how the application server operates on the HTTP query, so if the programmer went outside of a pre-imagined pattern, all bets about the WAF's security promises are off.
So I agree with the other comment in this thread about WAFs being snake oil. Good for pattern analysis and deep packet inspection to block specific known threats, but claiming it's a solution for all but the most basic SQL injection is a claim that can't be fulfilled.
The challenge of a WAF is it has no context of the application behind it. It doesn't really know what "good" input is for a specific application, so instead it tried to block "bad" things with a blacklist.
If the WAF ships with too strict of a blacklist, legit input gets block (All the people named "O'Brian" that can't use a web app...) If an attacker can make an attack look close enough to pass the blacklist, they win. In this example, the attacker had to remove whitespace, remove a math operation sign (=), and send english letters with a few special characters that could be in normal text (quote, forward slash, asterisk).
WAFs will never catch everything, and if they are advertised as such, that is snake oil. But WAFs can help by providing a ready made blacklist that can supplement input validation inside the app, which does have context about what valid input should look like.
I have also seen backend application which strip out certain "bad" tags (i.e. <script>).
I remember being able to perform an XSS attack by sending a payload that looked like:
<sc<script>ript>alert(/XSS/)</sc<script>ript>
This passed the WAF inspection, but then got trimmed by the backend application and this is what was left:
<script>alert(/XSS/)</script>
written in the page source.
Maybe I'll write about that case too if I find where I put the attack evidence.
You can anyway see that bad validation by the actual application programmers can disable the WAF's capabilities.
Obviously the correct solution for SQL injection is to use prepared statements or "proper" input validation.
I however wouldn't call WAF solutions snake oil...Web security in general follows an approach of layering Swiss cheese with holes in them, you hope that if you layer enough protection you can plug all the holes.
Leading WAF solutions have pretty decent coverage for SQLi and other payload attacks. If you're not sure of security in your code then your next best choices is a WAF.
Isn't it a fairly simple, mechanical job convert a non-parameterised query into a parameterised one. No non-local reasoning required. Things must bw pretty bad if you're running code with known SQL injection vulnerabilities!
1) You are the only one working on this project and there are no other people who may have varying experience levels or development schedules
2) You are in charge of all the software running on the machine and have the time to audit all of it
3) You are capable of writing software like this and didn't just contract it out to some firm
4) You are capable of writing software at all
WAFs are not perfect but there is clearly a market for them. It's not useful to high end tech companies because they have the in-house expertise (including red team/blue team staff) to avoid these pitfalls, which is expertise most small businesses and town/city-level govt agencies can't afford.
I believe you could handle that case with an escaping function for the `key` variable. Column names are generally quite restricted in what characters they can contain, so this is fairly easy to do in a water-tight way. Of course this won't restrict which column you're giving access to, but a WAF won't catch that either.
Definitely not snake oil if you’re running a popular off-the-shelf platform like Magento. The idea of WAFs is a bit like a virus scanner on a PC: it is designed to block known common heuristics from opportunists but it’s not there to block targeted attacks from hackers.
Right but I’m the context of antivirus you’re executing unconstrained data in an unconstrained environment, in appsec you can handle data correctly rather than rely on a third party product that can’t contextualise or assess the impact of a payload on your application. I work in appsec and think WAF filtering is snake oil.
You need to tweak your understanding of appsec to realize that most websites are run by non-technical people running old versions of off the shelf software attacked almost exclusively by automated drive-by attacks mass-scanning the internet.
If you don't see how WAFs could be useful, you may have been in the HN bubble too long thinking every website is some hand-coded Flask app.
You need to tweet your view of security requirements if you want to provide IT functions to users. Yes they are a nice to have, yes the cost of a data breach either to you or the user are highly damaging.
There’s nothing stopping most industries doing something stupid in the current state of things but I’m sure there will be in the future, you should be legally liable for your consumer data, irrespective of if you’re ‘nontechnical people running old versions of off the shelf software’ or not, mistakes happen, but failing the most obvious stuff in infosec is, IMO, criminally negligent. Waf or not.
You clearly haven’t worked in appsec that long if you haven’t already come across dozens of third party code bases that are supported either by people who don’t code or by over stretched developers that have no love for those specific platforms. Think low margin Wordpress sites, a CEOs friends Magento shop that your business ends up hosting for free, or some other CMS that predates the majority of your dev team (all of these cases I’ve personally experienced). Basically anything that adds enough value to the business to justify the hosting fees but not enough to justify development resource and thus often gets forgotten about. I’ve seen these instances pop up time and time again and while there is always the best of intentions keeping up with patches, WAF does at least increase the margin for error.
Or maybe I’m just not scraping bottom of the barrel when it comes to security assessments. If the software is at that point the organisation is well and truly fucked, waf or not.
A company running on off-the-shelf CMS for a product that adds value but isn’t part of the core business so that they can focus of the hard problems that differentiates themselves from their competitors is absolutely the correct way to run infrastructure.
You do actually realise that a significant amount of national and international news sites are actually powered by offs-the-shelf components and often even Wordpress? Equally true is the number of independent shops that run off-the-shelf applications. Then you have SaaS solutions that run a hosted blog (not everyone has switched to Medium), shops that still run message boards, and so on and so forth.
It’s got absolutely nothing b to do with the organisation failing and everything to do with investing your expensive talent on the problems that differentiate your business.
It’s easy to say “I work in yadda yadda yadda” anonymously but you’re still massively misrepresenting how the industry actually works with your sweeping generalisations. And if you were half as experienced as you pretend, you’d already know that. For example there is another use case of WAFs that hasn’t yet been discussed: automatic blacklisting. If they detect suspicious activity hitting services under the WAFs control they can automatically blacklist that source across all customers using that WAF service. This is similar to how fail2ban works but at a cloud level and with the added bonus of saving your sysadmins/DevOps engineers the pain of adding and maintaining thousands of apache / nginx rules themselves.
Let’s also not forget that there is good money to be made off consulting for those companies that are “fucked” and guiding them through best practices and low maintenance security models. That can often be a rewarding job in its own right (depending on the business).
No it’s not recommending snake oil and telling them to do things properly instead I don’t. Care if that makes the security industry dry up, my only hope is that if it does the snake oil salespeople die with it.
I get your point but I think Snake Oil might be too harsh. More like flu vaccine. Proven effective against an attack that was going around and similar attacks but not really guaranteed to prevent all strains of flu.
So no guarantees on whether it will solve all of your apps problems, but from a public health perspective likely to save VMs from getting owned in aggregate.
I wonder if it's possible to just go byte by byte, and try to parse the statement as valid SQL? If you use the same parser, or a compatible parser, to the backend DB you'd at least catch any valid SQL statements?
Ran into a funny bug once from either Cloudflare or AWS's implementation of a similar service.
Marketing made a big push for a new Promo code on the site we were running, but the promo code wasn't working. Reports came in that the promo code worked if you entered it as lowercase, rather than all caps.
Double-checked a dozen times, we take whatever string the user passes in an converted it to upper case, and all the values in the db were upper case. Keep thinking we must have messed this up somewhere.
In the end, the devops guy realizes that AWS (or Cloudflare, I forget) was blocking the uppercase requests, since the promo code was `SELECT` >.<
Assumed it was an injection attack, but only when uppercase.
I guess Marketing learned a valuable lesson about SQL keywords. It's also amusing to me because you know some engineer at Amazon must have brought up an edge case where a valid request would start with SELECT - but they were probably dismissed because how often would that happen - really?
I can't believe anyone who has ever actually used SQL for more than a few hours would not know the keywords are case-insensitive. More likely it was just someone given a list of keywords to filter out, with no mention of case-(in)sensitivity.
More likely an SDE-1 at Amazon 3 months out of college was given a sprint task and because they’ve only ever worked on nosql they had no idea about the edge cases of what they were asked to do.
We had a customer named Mr. Echo who was having difficulties paying us. Turns out our credit card processor was blocking the names of common Unix command line programs.
I hate these kind of defenses. If your application is vulnerable to sqli, select is one of many tools an attacker can use and you’re pretty much screwed anyway.
Instead, use sane tooling, like modern ORMs and parameter izers, with some data sanitation if you’re really paranoid.
The point of Cloudflare WAF isn't to be a main line of defense for HN readers, it's to stop the low effort automated drive-by attacks for websites that were already hosed. Like WAFs that block /wp-admin/* and instead generate a new segment.
I'd be surprised if there was a single person in the world who is going to go "oh right I should replace Cloudflare WAF and my sqli with some parameterized queries!"
I think ‘stop wasting time on dumb stuff and focus on actual security’ is a good take home for the HN crowd. Time and money is finite, so spend it wisely.
It's also "Hey the superstar on the sales team just launched a new Wordpress blog that everyone likes, just wanted to let you know" and you have no time for a detailed security audit. Put it behind Cloudflare and at least you're more protected than you were!
Nah you pull it offline and tell them to follow correct procurement and development practices. If your development teams aren’t talking to your security teams you have bigger problems than Wordpress.
Consider: Your org is more likely to be run by people that are like the sales people than like you. Who do you think they side with, when sales goes up the chain to complain development broke their new initiative and is saying it'll take 4x longer to do the thing they already did themselves, and as a direct result means they won't hit revenue numbers this quarter?
What's even the risk here? Some minor marketing sub-site gets defaced, causing - at worst - an embarassing but instantly-forgotten incident?
No the risk is that somebody has decided to disregard security and general security process and create shadow IT, which if left unchecked will create massive problems within the organisation long term. If the culture is to disregard security, throw a waf infront and call it a day then they’ll pay for it financially (and possibly legally) in the long run and not something I’d want to associate with at all.
It took me far too long puzzling over how "tardigrade" would be a keyword for an injection attack of any sort, and the closest I came to a guess was "tard" (as in "retard") being blocked for offence, so for those like me who didn't see that story: https://news.ycombinator.com/item?id=24450828
Sometimes you need to stop something fast, and the overly broad thing like 'block any mention of tardigrade' so 'we don't go to jail' thing is needed until you can refine the regex to not be so greedy.
you just have to be willing to go back to do the refinement once the bleeding stops.
We’ve had a couple of similar issues with AWS WAF recently, in one case it blocked any request body containing :// (i.e. any URL) claiming it was a file system path. In the other we had a 3rd party cookie containing `= null` and the WAF thought it was sqli. I guess I can see the argument about layering multiple imperfect defences, but we wasted hours diagnosing these, neither were real issues, so I’m not sold on the value at this point.
Many of WAF's canned rule sets are ridiculously broad. I'm content to use the low-reputation-IP rules, but almost nothing else is advisable, unless you're intent on exposing (and not fixing?) a badly-written service to the world.
The low reputation IP rules are a pain in the arse -- and I say that as someone who frequently falls foul of them. I often have to use tor to get around government blocks. The fact that Google and cloudfare hate tor users is just an extra kick in the teeth.
If your web app is vulnerable being brute forced, fix it, don't blame the users...
Yes, Cloudflare stores the SSL the private keys. CDNs really need to read and modify the requests and responses for most of their functionality, like caching, load balancing, DOS mitigation, ...
You can always use a separate, not CDN protected domain for your API if this is a threat vector you care about.
Is there a name for the fallacy when people say something like "you shouldn't be using this to protect your app anyway - doing so will give you a false sense of security and make you write riskier code"? I see this argument quite often for features like this that give partial protection. It's partly a false dilemma anyway.
The argument is usually that you can at least circumvent automated scanners with a WAF. Thst point is pretty moot with Cloudflare powering a double digit percentage of all website, though.
What "fallacy"? I'm actually horrified that several high profile companies are proudly advertising using this abomination on https://www.cloudflare.com/waf/.
I really do not want to use the product of a company that thinks it's a good idea to "protect" their software by paying someone to put something in front of it that strips out all input that "looks too much like SQL".
This is a bit like a food manufacturer paying someone to add antibiotics to their products because their hygiene processes are so terrible they suspect some E. coli might slip in from time to time.
Unlike say the insane sing-and-dance-de-jour you have to perform to make sure your server sets the right set of security related HTTP headers, SQL injection attacks, despite their prevalence, are a completely bogus problem. I'd go so far and say if you have an SQL Injection attack, the solution is to fire someone and review your processes and not to pay a third party to corrupt data coming in and cross your fingers and hope that they do so in a way that will hopefully both protect you from your engineering incompetence and not mess up genuine requests too much.
> I'd go so far and say if you have an SQL Injection attack, the solution is to fire someone and review your processes and not to pay a third party to corrupt data coming in
The fallacy you're making is proposing a false dilemma. You can review your processes AND layer defences on top. You don't have to pick between one or the other.
Whether Cloudflare is a worthwhile defence is not what I'm commenting on though, although surely the whole point of it is that it gives you some protection when you don't know you have an SQL injection exploit. I can't imagine anyone knows they have exploits and is using Cloudflare as a solution/bandaid.
And the fallacy you are making is describing adding more shit sauce on top as "a layered defense". A layered defense is when you take multiple, individually sane steps, with well defined boundaries to reduce risks that remain despite following good engineering practice. Some aspects of WAF may fit this bill, but SQL Injection defence assuredly does not.
There is no way in hell that something that basically takes arbitrary input without any context and says "oh, well, this looks a bit too much like an SQL fragment for my liking, let's corrupt it a bit, lest some piece of garbage downstream tries to string interpolate executable code together with it and it'll end in tears" will not, in some cases, cause other problems, maybe even security-relevant ones.
It's real easy not to have SQL injection exploits, you inform people that using anything apart from prepared statements to talk to the DB is a firing offence. If software vendors would face liability claims as other engineering professions do, this would be fixed overnight. As things are, I'm 100% sure you are wrong and there are countless places that do know they have exploits and just slap Cloudflare on top as a bandaid.
> And the fallacy you are making is describing adding more shit sauce on top as "a layered defense". A layered defense is when you take multiple, individually sane steps, with well defined boundaries to reduce risks that remain despite following good engineering practice. Some aspects of WAF may fit this bill, but SQL Injection defence assuredly does not.
I haven't commented about how effective WAF is or if you should use it or not, so you're on a soapbox attacking a strawman here.
> It's real easy not to have SQL injection exploits, you inform people that using anything apart from prepared statements to talk to the DB is a firing offence.
I think relying on nobody to make mistakes (because you tried to scare them not to or otherwise) is awful advice in general. Even frameworks you rely on to create safe SQL queries can have exploits as well so you need to consider human error at several layers.
Expect human error and plan your processes around it.
>This is a bit like a food manufacturer paying someone to add antibiotics to their products because their hygiene processes are so terrible they suspect some E. coli might slip in from time to time.
and apparently FDA being paid in free Tshirts for testing food safety
“The safest way to mitigate SQL injections on your databases is prepared statements. These come in most database interaction libraries for most languages. You can find a full list of ways to mitigate SQL injections at [OWASP].”
A hidden "SQL injection filter" in cloudflare seems like a truly awful idea.
What happens when an incompetent developer codes up a vulnerable website, and it seems to be protected through this feature, and this goes unnoticed for many years until cloudflare is phased out, the feature is disabled, or some other change to the way things are done outside the original dev's control comes along?
And what happens when you can bypass it as soon as there is some other way (i.e. base64 encoded, or not in HTTP at all) for user input to reach the API?
And of course, what happens when you can bypass it due to it having a bug or being deficient by design?
The lesson: do NOT "sanitize" your inputs, ever. Just keep your data types straight (by using things like prepared statements to convert a string to an SQL-escaped string) and block all inputs that should never end up in the database in the first place.
If you ever need this or something like this, then it means you don't trust 100% how input is handled. I think my projects reached this point, even with some little flaws in between, to expect this from any company that isn't organised enough to handle security properly.. sounds unteslistic. From there it just depends at which cost you add this additional layer of "security", I learned from cloudbleed to avoid as much as posible anything that could modify the document in some way.
106 comments
[ 3.5 ms ] story [ 179 ms ] threadJust a few examples: https://github.com/frizb/Bypassing-Web-Application-Firewalls
https://www.google.com/amp/s/www.zdnet.com/google-amp/articl...
That applies to everything security related. "Don't review your source code for vulnerabilities, it may lull you into a false sense of security."
There are occasions though where WAFs can be somewhat useful, like where you need to secure a vendors webapp that you can't patch without them releasing a fix or trust, but for legacy or business reasons are required to run.
So some of us are forced to buy and implement these products regardless of effectiveness, and it is helpful to see how vendors respond I think.
WAFs definitely help. No WAF is perfect, but having an additional layer to make exploitation harder, and having a tool designed to block specific attacks (like when a new CVE is issued for a CMS) is powerful.
Not to mention that WAFs are a requirement in regulated industries. PCI mandates it. And your SOC2 + ISO auditors probably will ask about it too.
A good set of filters deters casual abusers and can amplify the signal from a skilled attack, but ultimately they tend to fail.
the major challenges i've seen with WAFs on that front are that users treat them (and often, any part of a security solution) as a panacea for general classes of problems, which they aren't. WAFs can provide excellent targeted defense ("this request looks like it's trying to exploit CVE-2020-4521 specifically, I should almost certainly block it") and very mediocre general defense ("this request kinda looks like it might be SQLi--block it?").
the latter suffers from the issues others have raised in adjacent comments: the WAF doesn't know if the defended application applies its own sanitization (it should, but for its function, the WAF assumes that upstream doesn't, and could be vulnerable) and/or if the request content is something that reasonably should include SQLi-like content. The Cloudflare WAF in particular, at least circa 2018, suffered from including a lot of OWASP project rules that could spot "naked" SQLi quite easily, but in doing so also triggered on a lot content where the appearance of SQLi was, in fact, normal usage of punctuation characters where they made sense in plain English prose--someone can and should legitimately use quotation marks in the course of writing a prose English comment, like I'm doing right now, along with an occasional semicolon or paren alongside quotes, because those same symbols have meaning and use in both SQL and English prose.
this leads to lots of fun user confusion scenarios, where someone on the sales side of thing says "yes! enable the WAF! more protection = more product value for you!", and some months after, someone on the support side says "sorry, but the WAF can also generate false positives on legit text content, or can miss legit malicious content if it's gift-wrapped effectively (a la the OP)".
that sort of nuance is really hard to understand for more naive users, who can't easily distinguish between "the WAF blocks things it can positively ID as threats", "the WAF blocks things it mistakenly identifies as a threat based on superficial similarity to actual threats", and "the WAF doesn't block things that are threats, but are crafted to avoid the WAF". Users just see ~WAF~, and unfortunately often see it as technological wizardry that does or should just work, because it's magic. It ain't, but communicating the nuances, to a general audience? That's damn hard, and has long been neglected across industry because it doesn't fit well into shiny marketing copy.
technical improvements are valuable, but they can only go so far--at some point, there's greater value in educational content that helps dispel the magic somewhat, so that users understand the shortcomings of any given tool and can spot when those shortcomings arise. Thankfully the whole Cloudflare TV project and other educational content does seem to be progressing, though im unfortunately too far removed from the day to day now to see how well it's succeeding :) optimism hat on, it is, and godspeed!
Perfect, exactly what most people lack.
It's simply impossible to consistently recruit developers with good security knowledge, especially if we want, as an industry, to take responsibility for getting new developers up the first few rungs of the ladder.
And you do need a mechanism that can provide defense for legacy applications, or to quickly mitigate 0-days.
As long as we can't guarantee that developers won't screw up, we need tools for cyber-security to mitigate these attacks. WAFs and other layered security devices do fill that need.
However!
Any layered security device must be bypassable. Your WAF is probably configured by the same people who make the automated security tests your pen-testers run.
If your pen-testers aren't bypassing layered security and attacking your application directly, then you're not really doing layered security anymore. Your WAF's security becomes snake oil, and your application's security is untested.
At the end of the day, the red team always wins. Tactical risk mitigation, segmentation and logging are the way to address security. Best case, your monitoring detects and alerts on the guy attacking the WAF, otherwise you have logs to conduct an investigation later.
wait, I thought "And All I Got Was This Lousy T-Shirt" was just a meme
[0] https://twitter.com/giovannichhatta/status/93148007899067596...
> Reporters under the age of 18 will not be eligible to receive Cloudflare service rewards
https://hackerone.com/cloudflare
>Cloudflare runs a private bug bounty program. If you submit a valid report on bounty-eligible assets through our disclosure program, we will transfer your report to our bug bounty program and invite you as a participant.
Or are there still vulns/exploits for that kind of usage?
As one example of this consider the rails vuln CVE-2013-0156. Lax param parsing and cleaning (or none), can lead to problems like this and even sqli if you meant to accept a string and instead accept something like an array or a symbol.
It doesn't mean you're safe in other contexts though. For example if you allow reading another user's data without checking permissions, you've got an IDOR vulnerability. https://portswigger.net/web-security/access-control/idor
You can go further by actually validating types (e.g. “id should be a number between 1 and 20 digits”) but I'd class that more as general input validation since you want to do that everywhere even if you don't have SQL database.
To me, it seems like it's not possible for a WAF to honestly promise "SQL Injection Prevention," because it's surely just string matching and not actually building an AST/simulating a database query before passing the HTTP query along to the application server. The WAF can't possibly know how the application server operates on the HTTP query, so if the programmer went outside of a pre-imagined pattern, all bets about the WAF's security promises are off.
So I agree with the other comment in this thread about WAFs being snake oil. Good for pattern analysis and deep packet inspection to block specific known threats, but claiming it's a solution for all but the most basic SQL injection is a claim that can't be fulfilled.
If they are selling it as foolproof, "snake oil" may be fair, but it does still seem to have some value.
If the WAF ships with too strict of a blacklist, legit input gets block (All the people named "O'Brian" that can't use a web app...) If an attacker can make an attack look close enough to pass the blacklist, they win. In this example, the attacker had to remove whitespace, remove a math operation sign (=), and send english letters with a few special characters that could be in normal text (quote, forward slash, asterisk).
WAFs will never catch everything, and if they are advertised as such, that is snake oil. But WAFs can help by providing a ready made blacklist that can supplement input validation inside the app, which does have context about what valid input should look like.
I remember being able to perform an XSS attack by sending a payload that looked like:
<sc<script>ript>alert(/XSS/)</sc<script>ript>
This passed the WAF inspection, but then got trimmed by the backend application and this is what was left:
<script>alert(/XSS/)</script>
written in the page source.
Maybe I'll write about that case too if I find where I put the attack evidence. You can anyway see that bad validation by the actual application programmers can disable the WAF's capabilities.
I however wouldn't call WAF solutions snake oil...Web security in general follows an approach of layering Swiss cheese with holes in them, you hope that if you layer enough protection you can plug all the holes.
Leading WAF solutions have pretty decent coverage for SQLi and other payload attacks. If you're not sure of security in your code then your next best choices is a WAF.
1) You are the only one working on this project and there are no other people who may have varying experience levels or development schedules
2) You are in charge of all the software running on the machine and have the time to audit all of it
3) You are capable of writing software like this and didn't just contract it out to some firm
4) You are capable of writing software at all
WAFs are not perfect but there is clearly a market for them. It's not useful to high end tech companies because they have the in-house expertise (including red team/blue team staff) to avoid these pitfalls, which is expertise most small businesses and town/city-level govt agencies can't afford.
They are. That doesn't work. There is no good reason to concatenate user input into a query, full stop.
If you don't see how WAFs could be useful, you may have been in the HN bubble too long thinking every website is some hand-coded Flask app.
There’s nothing stopping most industries doing something stupid in the current state of things but I’m sure there will be in the future, you should be legally liable for your consumer data, irrespective of if you’re ‘nontechnical people running old versions of off the shelf software’ or not, mistakes happen, but failing the most obvious stuff in infosec is, IMO, criminally negligent. Waf or not.
You do actually realise that a significant amount of national and international news sites are actually powered by offs-the-shelf components and often even Wordpress? Equally true is the number of independent shops that run off-the-shelf applications. Then you have SaaS solutions that run a hosted blog (not everyone has switched to Medium), shops that still run message boards, and so on and so forth.
It’s got absolutely nothing b to do with the organisation failing and everything to do with investing your expensive talent on the problems that differentiate your business.
It’s easy to say “I work in yadda yadda yadda” anonymously but you’re still massively misrepresenting how the industry actually works with your sweeping generalisations. And if you were half as experienced as you pretend, you’d already know that. For example there is another use case of WAFs that hasn’t yet been discussed: automatic blacklisting. If they detect suspicious activity hitting services under the WAFs control they can automatically blacklist that source across all customers using that WAF service. This is similar to how fail2ban works but at a cloud level and with the added bonus of saving your sysadmins/DevOps engineers the pain of adding and maintaining thousands of apache / nginx rules themselves.
Let’s also not forget that there is good money to be made off consulting for those companies that are “fucked” and guiding them through best practices and low maintenance security models. That can often be a rewarding job in its own right (depending on the business).
> Let’s also not forget that there is good money to be made off consulting for those companies that are “fucked”
Where the hell are your ethics?
So no guarantees on whether it will solve all of your apps problems, but from a public health perspective likely to save VMs from getting owned in aggregate.
Select a, b from foo;
Marketing made a big push for a new Promo code on the site we were running, but the promo code wasn't working. Reports came in that the promo code worked if you entered it as lowercase, rather than all caps.
Double-checked a dozen times, we take whatever string the user passes in an converted it to upper case, and all the values in the db were upper case. Keep thinking we must have messed this up somewhere.
In the end, the devops guy realizes that AWS (or Cloudflare, I forget) was blocking the uppercase requests, since the promo code was `SELECT` >.<
Assumed it was an injection attack, but only when uppercase.
Yes, how a person making a minimum of $100K/y could know such things.
Instead, use sane tooling, like modern ORMs and parameter izers, with some data sanitation if you’re really paranoid.
You're misunderstanding the market.
The point of Cloudflare WAF isn't to be a main line of defense for HN readers, it's to stop the low effort automated drive-by attacks for websites that were already hosed. Like WAFs that block /wp-admin/* and instead generate a new segment.
I'd be surprised if there was a single person in the world who is going to go "oh right I should replace Cloudflare WAF and my sqli with some parameterized queries!"
What's even the risk here? Some minor marketing sub-site gets defaced, causing - at worst - an embarassing but instantly-forgotten incident?
An overreaction is sometimes an overreaction, not a good defence.
you just have to be willing to go back to do the refinement once the bleeding stops.
If your web app is vulnerable being brute forced, fix it, don't blame the users...
Genuine question, I never used one of these services.
You can always use a separate, not CDN protected domain for your API if this is a threat vector you care about.
I really do not want to use the product of a company that thinks it's a good idea to "protect" their software by paying someone to put something in front of it that strips out all input that "looks too much like SQL".
This is a bit like a food manufacturer paying someone to add antibiotics to their products because their hygiene processes are so terrible they suspect some E. coli might slip in from time to time.
Unlike say the insane sing-and-dance-de-jour you have to perform to make sure your server sets the right set of security related HTTP headers, SQL injection attacks, despite their prevalence, are a completely bogus problem. I'd go so far and say if you have an SQL Injection attack, the solution is to fire someone and review your processes and not to pay a third party to corrupt data coming in and cross your fingers and hope that they do so in a way that will hopefully both protect you from your engineering incompetence and not mess up genuine requests too much.
The fallacy you're making is proposing a false dilemma. You can review your processes AND layer defences on top. You don't have to pick between one or the other.
Whether Cloudflare is a worthwhile defence is not what I'm commenting on though, although surely the whole point of it is that it gives you some protection when you don't know you have an SQL injection exploit. I can't imagine anyone knows they have exploits and is using Cloudflare as a solution/bandaid.
There is no way in hell that something that basically takes arbitrary input without any context and says "oh, well, this looks a bit too much like an SQL fragment for my liking, let's corrupt it a bit, lest some piece of garbage downstream tries to string interpolate executable code together with it and it'll end in tears" will not, in some cases, cause other problems, maybe even security-relevant ones.
It's real easy not to have SQL injection exploits, you inform people that using anything apart from prepared statements to talk to the DB is a firing offence. If software vendors would face liability claims as other engineering professions do, this would be fixed overnight. As things are, I'm 100% sure you are wrong and there are countless places that do know they have exploits and just slap Cloudflare on top as a bandaid.
I haven't commented about how effective WAF is or if you should use it or not, so you're on a soapbox attacking a strawman here.
> It's real easy not to have SQL injection exploits, you inform people that using anything apart from prepared statements to talk to the DB is a firing offence.
I think relying on nobody to make mistakes (because you tried to scare them not to or otherwise) is awful advice in general. Even frameworks you rely on to create safe SQL queries can have exploits as well so you need to consider human error at several layers.
Expect human error and plan your processes around it.
and apparently FDA being paid in free Tshirts for testing food safety
"Can we remove that?"
> "No, it could open up vulnerabilities"
Yup. Yes, it could. Silly me.
“The safest way to mitigate SQL injections on your databases is prepared statements. These come in most database interaction libraries for most languages. You can find a full list of ways to mitigate SQL injections at [OWASP].”
[OWASP]: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection...
What happens when an incompetent developer codes up a vulnerable website, and it seems to be protected through this feature, and this goes unnoticed for many years until cloudflare is phased out, the feature is disabled, or some other change to the way things are done outside the original dev's control comes along?
And what happens when you can bypass it as soon as there is some other way (i.e. base64 encoded, or not in HTTP at all) for user input to reach the API?
And of course, what happens when you can bypass it due to it having a bug or being deficient by design?
The lesson: do NOT "sanitize" your inputs, ever. Just keep your data types straight (by using things like prepared statements to convert a string to an SQL-escaped string) and block all inputs that should never end up in the database in the first place.