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.

> "proper" input validation.

They are. That doesn't work. There is no good reason to concatenate user input into a query, full stop.

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!

Until you run across code that's doing something like:

    def search(key, value):
        query("select * from my_table where `" + key + "` = '" + value + "'")

Not that I'm suggesting this is a good thing to do, but it's not something you can simply replace with a single line of context or easily.

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.

This makes a lot of assumptions, for example:

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.

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.

Isn’t the correct solution to replace '<' and '>' with '&lt;' and '&gt;'?

The correct solution is to apply Content-Security-Policy plus character escaping as needed.

Yeah, escaping entities when rendering, using prepared statements in the database. It's not rocket science.

Or, you know, using ordinary SGML validation which has the capability to block disallowed elements since 1986.

amen

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 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).

I’ll ignore your condescending dribble but:

> 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?

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.

So your approach of "not scraping bottom of the barrel" and not helping such companies is more ethical?

See comment on parent.

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.

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.

There least I heard their WAF is just Apache's mod_security rules transpiled to Lua. So yes it's pretty much just regexes

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?

What if the payload is ‘a,b’ which renders as

Select a, b from foo;

It could, but that type of mitigation can make the backend susceptible to a DoS. It can definitely be coded that way, just take a little extra care.

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.