7 ms·

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 pr

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.
  - colejohnson66 6y ago
    Isn’t the correct solution to replace '<' and '>' with '<' and '>'?
    - krapp 6y ago
      Yeah, escaping entities when rendering, using prepared statements in the database. It's not rocket science.
      - gskourou 6y ago
        amen
      - tannhaeuser 6y ago
        Or, you know, using ordinary SGML validation which has the capability to block disallowed elements since 1986.
    - yyyk 6y ago
      The correct solution is to apply Content-Security-Policy plus character escaping as needed.
Edmond 6y ago
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.
- deleted 6y ago
  [deleted]
- nicoburns 6y ago
  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!
  - deleted 6y ago
    [deleted]
  - nexuist 6y ago
    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.
  - nucleardog 6y ago
    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.
IncRnd 6y ago
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.
laumars 6y ago
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.
- Bnshsysjab 6y ago
  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.
  - hombre_fatal 6y ago
    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.
    - Bnshsysjab 6y ago
      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.
  - laumars 6y ago
    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.
shanemhansen 6y ago
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.
staticassertion 6y ago
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?
- Bnshsysjab 6y ago
  What if the payload is ‘a,b’ which renders as Select a, b from foo;
VWWHFSfQ 6y ago
There least I heard their WAF is just Apache's mod_security rules transpiled to Lua. So yes it's pretty much just regexes

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.
- colejohnson66 6y ago
  Isn’t the correct solution to replace '<' and '>' with '<' and '>'?
  - krapp 6y ago
    Yeah, escaping entities when rendering, using prepared statements in the database. It's not rocket science.
    - gskourou 6y ago
      amen
    - tannhaeuser 6y ago
      Or, you know, using ordinary SGML validation which has the capability to block disallowed elements since 1986.
  - yyyk 6y ago
    The correct solution is to apply Content-Security-Policy plus character escaping as needed.

Edmond 6y ago

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.

deleted 6y ago
[deleted]
nicoburns 6y ago
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!
- deleted 6y ago
  [deleted]
- nexuist 6y ago
  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.
- nucleardog 6y ago
  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.

IncRnd 6y ago

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.

laumars 6y ago

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.

Bnshsysjab 6y ago
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.
- hombre_fatal 6y ago
  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.
  - Bnshsysjab 6y ago
    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.
- laumars 6y ago
  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.

shanemhansen 6y ago

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.

staticassertion 6y ago

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?

Bnshsysjab 6y ago
What if the payload is ‘a,b’ which renders as Select a, b from foo;

VWWHFSfQ 6y ago

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