11 ms·

How I bypassed Cloudflare's SQL Injection filter

235 points by gskourou 6y ago

girst 6y ago
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. Just a few examples: https://github.com/frizb/Bypassing-Web-Application-Firewalls https://github.com/frizb/Bypassing-Web-Application-Firewalls
- itsdrewmiller 6y ago
  “Not invulnerable” is not the same as snake oil. WAFs are a useful piece of a defense in depth strategy.
  - girst 6y ago
    Or they can lull you into a false sense of security. (which is the reason chrom{e,ium} has removed their XSS auditor)
    - itsdrewmiller 6y ago
      That doesn’t seem to be true - googling says they removed it because it became too bad at doing its job and they didn’t want to maintain it. https://www.google.com/amp/s/www.zdnet.com/google-amp/article/google-to-remove-chromes-built-in-xss-protection-xss-auditor/ https://www.google.com/amp/s/www.zdnet.com/google-amp/articl...
    - marcinzm 6y ago
      >Or they can lull you into a false sense of security. That applies to everything security related. "Don't review your source code for vulnerabilities, it may lull you into a false sense of security."
- tus88 6y ago
  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.
- mhh__ 6y ago
  Wouldn't it be closer to something like Denuvo - the ambitious, skilled, people can get in but the script kiddies can't i.e. it buys you time
- beh9540 6y ago
  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.
  - donmcronald 6y ago
    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.
- ejcx 6y ago
  (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.
  - jcims 6y ago
    For me the main benefit of a WAF is that ability to rapidly respond to zero day/CVE. A good set of filters deters casual abusers and can amplify the signal from a skilled attack, but ultimately they tend to fail.
  - fivre 6y ago
    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__/ 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!
- icecap12 6y ago
  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.
  - sk5t 6y ago
    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!
- dj_mc_merlin 6y ago
  > (with enough time and determination) Perfect, exactly what most people lack.
- ben509 6y ago
  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.
- Spooky23 6y ago
  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.
rasz 6y ago
>I got a free t-shirt wait, I thought "And All I Got Was This Lousy T-Shirt" was just a meme
- dutchmartin 6y ago
  It is not. The Dutch government also sends T-shirts to hackers that disclosed a security vulnerability[0]. [0] https://twitter.com/giovannichhatta/status/931480078990675968?s=20 https://twitter.com/giovannichhatta/status/93148007899067596...
- judge2020 6y ago
  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 https://hackerone.com/cloudflare https://hackerone.com/cloudflare
  - bruno207 6y ago
    Check the top: >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.
Snitch-Thursday 6y ago
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?
- gskourou 6y ago
  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-parameterized-statement-stop-all-sql-injection https://stackoverflow.com/questions/6786034/can-parameterize...
- grey-area 6y ago
  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.
  - nkozyra 6y ago
    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.
    - grey-area 6y ago
      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.
- 6y ago
akersten 6y ago
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.
- tyingq 6y ago
  Snake oil seems pretty strong. There's surely lots of SQL injections floating around that don't play the arms escalation game. If they are selling it as foolproof, "snake oil" may be fair, but it does still seem to have some value.
- billyhoffman 6y ago
  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.
  - gskourou 6y ago
    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.
jonahss 6y ago
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.
- BitwiseFool 6y ago
  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?
  - divbzero 6y ago
    Also amusing is the thought that lowercase "select" is any safer than uppercase "SELECT".
    - userbinator 6y ago
      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.
      - dylan604 6y ago
        is case sensitivity training available through HR we can send the new recruits?
        6y ago
seanwilson 6y ago
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.
- Sebb767 6y ago
  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.
- patrec 6y ago
  What "fallacy"? I'm actually horrified that several high profile companies are proudly advertising using this abomination on https://www.cloudflare.com/waf/ 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.
  - deleted 6y ago
    [deleted]
  - seanwilson 6y ago
    > 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.
beaker52 6y ago
A recent client of mine had their WAF configured to block requests with '%' in the URL. Yup. No URL encoding. "Can we remove that?" > "No, it could open up vulnerabilities" Yup. Yes, it could. Silly me.
divbzero 6y ago
Highlighting the key PSA from the article: “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_Prevention_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection...
creatonez 6y ago
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.
unlog 6y ago
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.
DoctorNick 6y ago
All you got was a lousy t-shirt? You could have easily sold that on the black market for tens of thousands of dollars.
- ivanche 6y ago
  True, but now he has a $0.50 t-shirt! /s

235 points by gskourou 6y ago

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. Just a few examples: https://github.com/frizb/Bypassing-Web-Application-Firewalls https://github.com/frizb/Bypassing-Web-Application-Firewalls

itsdrewmiller 6y ago
“Not invulnerable” is not the same as snake oil. WAFs are a useful piece of a defense in depth strategy.
- girst 6y ago
  Or they can lull you into a false sense of security. (which is the reason chrom{e,ium} has removed their XSS auditor)
  - itsdrewmiller 6y ago
    That doesn’t seem to be true - googling says they removed it because it became too bad at doing its job and they didn’t want to maintain it. https://www.google.com/amp/s/www.zdnet.com/google-amp/article/google-to-remove-chromes-built-in-xss-protection-xss-auditor/ https://www.google.com/amp/s/www.zdnet.com/google-amp/articl...
  - marcinzm 6y ago
    >Or they can lull you into a false sense of security. That applies to everything security related. "Don't review your source code for vulnerabilities, it may lull you into a false sense of security."
tus88 6y ago
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.
mhh__ 6y ago
Wouldn't it be closer to something like Denuvo - the ambitious, skilled, people can get in but the script kiddies can't i.e. it buys you time
beh9540 6y ago
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.
- donmcronald 6y ago
  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.
ejcx 6y ago
(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.
- jcims 6y ago
  For me the main benefit of a WAF is that ability to rapidly respond to zero day/CVE. A good set of filters deters casual abusers and can amplify the signal from a skilled attack, but ultimately they tend to fail.
- fivre 6y ago
  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__/ 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!
icecap12 6y ago
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.
- sk5t 6y ago
  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!
dj_mc_merlin 6y ago
> (with enough time and determination) Perfect, exactly what most people lack.
ben509 6y ago
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.
Spooky23 6y ago
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.

rasz 6y ago

>I got a free t-shirt wait, I thought "And All I Got Was This Lousy T-Shirt" was just a meme

dutchmartin 6y ago
It is not. The Dutch government also sends T-shirts to hackers that disclosed a security vulnerability[0]. [0] https://twitter.com/giovannichhatta/status/931480078990675968?s=20 https://twitter.com/giovannichhatta/status/93148007899067596...
judge2020 6y ago
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 https://hackerone.com/cloudflare https://hackerone.com/cloudflare
- bruno207 6y ago
  Check the top: >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.

Snitch-Thursday 6y ago

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?

gskourou 6y ago
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-parameterized-statement-stop-all-sql-injection https://stackoverflow.com/questions/6786034/can-parameterize...
grey-area 6y ago
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.
- nkozyra 6y ago
  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.
  - grey-area 6y ago
    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.
6y ago

akersten 6y ago

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.

tyingq 6y ago
Snake oil seems pretty strong. There's surely lots of SQL injections floating around that don't play the arms escalation game. If they are selling it as foolproof, "snake oil" may be fair, but it does still seem to have some value.
billyhoffman 6y ago
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.
- gskourou 6y ago
  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.

jonahss 6y ago

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.

BitwiseFool 6y ago
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?
- divbzero 6y ago
  Also amusing is the thought that lowercase "select" is any safer than uppercase "SELECT".
  - userbinator 6y ago
    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.
    - dylan604 6y ago
      is case sensitivity training available through HR we can send the new recruits?
      - 6y ago

seanwilson 6y ago

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.

Sebb767 6y ago
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.
patrec 6y ago
What "fallacy"? I'm actually horrified that several high profile companies are proudly advertising using this abomination on https://www.cloudflare.com/waf/ 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.
- deleted 6y ago
  [deleted]
- seanwilson 6y ago
  > 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.

beaker52 6y ago

A recent client of mine had their WAF configured to block requests with '%' in the URL. Yup. No URL encoding. "Can we remove that?" > "No, it could open up vulnerabilities" Yup. Yes, it could. Silly me.

divbzero 6y ago

Highlighting the key PSA from the article: “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_Prevention_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection...

creatonez 6y ago

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.

unlog 6y ago

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.

DoctorNick 6y ago

All you got was a lousy t-shirt? You could have easily sold that on the black market for tens of thousands of dollars.

ivanche 6y ago
True, but now he has a $0.50 t-shirt! /s