How I bypassed Cloudflare's SQL Injection filter
astrocamel.com
astrocamel.com
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.
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.
def search(key, value):
query("select * from my_table where `" + key + "` = '" + value + "'")
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;
“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...
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
>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.
"Can we remove that?"
> "No, it could open up vulnerabilities"
Yup. Yes, it could. Silly me.
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.
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.
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
Just 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.