Hi, does the Cloudflare WAF cover this new SQL injection technique presented by Claroty’s research team yesterday at BackHat Europe, where some WAF vendors were listed as bypassed? Does the WAF parse this attack pattern in parameters both in url but also in the POST body ?
Thanks.
does the Cloudflare WAF cover this new SQL injection technique presented by Claroty’s research team yesterday at BackHat Europe, where some WAF vendors were listed as bypassed?
I read the article you linked to, so if you missed this part, here it is again:
- Our bypass worked against WAFs sold by five leading vendors: Palo Alto Networks, Amazon Web Services, Cloudflare, F5, and Imperva. All five have been notified and have updated their products to support JSON syntax in their SQL injection inspection process.
(emphasis mine)
Furthermore, while that’s great research and certainly a rather enticing article headline, it kinda glosses over the very obvious core fact…
Anybody relying on a WAF to keep his database save is doomed from the start. WAFs certainly help to filter some attacks, and reduce the intensity of others… But in particular SQL injections are reliably stopped by one thing, and one thing only - SQL statement parameterization. If you don’t have that, it’s only a question of time until you will get hit by a SQLi attack.
I generally agree with you, but to be fair, one does not always need prepared statements. One does, however, need to make sure that strings are properly escaped. That can be using prepared statements but does not have to be.
Yes, this is the best practice, but lazy programmers are still out there in numbers and any application that handles data inputs more complex than a context-free grammar is at risk.
In general with the WAF you should hope for the best and prepare for the worst.
Cloudflare’s WAF is good. But even it has things it can’t catch (as seen here) and so you should program in a way that ensures anything that gets through won’t cause issues.
Statement parameterization is not prepared statements. It’s simply separating your ad-hoc query and its parameters.
(And btw, this is great for your performance, too. It makes it much easier for the DB to cache parsed statements and sometimes even results!)
And escaping is a nice idea. But time has shown that there are always one or the other way around escaping, especially with all the different collations and such. Parameterization OTOH just doesn’t have that problem, as the DB will never interpret these parameters as executable input.
Lazy programmers is simply not an excuse. No WAF, no framework, no nothing will save you long run if you completely ignore 3 decades of web security basics.
Injection attacks have been in the top 3 of OWASP since its bloody inception. Anybody who still doesn’t care about proper data input hygiene literally needs to go back to bootcamp.
Well, databases typically provide no other way than prepared statements. How much that is behind syntactic sugar is a question of the database and the language you are using.
The link you provided specifically refers to prepared statements.
Then your escape logic is broken, but if you properly use escaping it absolutely is the equivalent of statement parameterization, in particular if you are not using prepared statements.
OK, my terminology was possibly a bit off here.
These example and cases may or may not rely on “preparing” a statement. But that is, at least for the programmers using such API / library, a purely in-code client side thing.
It is notably different from “stored procedures”, which historically and practically have been very cumbersome.
So no matter how exactly one calls it, there are readily available and simple to use tools in every web facing language / framework / … to properly and securely handle external inputs. And securely means not doing some kind of string magic but separating logic and inputs.
And these securely is not just escaping inputs…
Escaping is not reliable.
Just look the following list of SQL injection CVEs
… and search for how many times escape / escaping / sanitise / sanitize / etc comes up.
Please folks, separate your inputs from your SQL statements. Don’t just concatenate everything into one big string.
We don’t process user inputs by using eval()in JavaScript these days either, right? Right?? 
Was not referring to stored procedures at all. I was only talking about the additional overhead of prepared statements.
Sorry, but that is simply wrong.
As I already wrote, if you do it properly, it is reliable. If you don’t, it naturally cannot be.
I presume you meant to send a different link, but I never said an SQL injection is not a serious issue. But that is not an issue of proper escaping, rather the very absence of it.
Don’t get me wrong, I am not advocating one huge string orgy. However, one should not demonise concatenation either, it really depends on what you are doing and a developer should know when to use what.
Then again, of course, in the context we have here, we still have PHP 5 setups and an astounding general carefreeness towards basic security - so I guess we should take everything with a grain of salt 
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.
