0

I would like to use haproxy (1.7.5-2 2017/05/17, debian stretch stock) as a first line of defense against some possible attacks (e.g. SQL injection). The idea is that I create an acl in the frontend that detects unwanted patterns using regexps and then use an always-failing dummy backend in that case. Something like this:

acl sql_injection url_reg -i -f /etc/haproxy/sqlinject.patterns
use_backend bad_request if sql_injection

The problem is, that if the url is url-encoded, then e.g. foo.com/?select foo from bar would be transmitted as foo.com/?select%20 foo%20from%20bar, which really needs a different regexp, and thus a matching regexp would bee unnecessarily broad. Hence come url_dec:

acl sql_injection url_reg,url_dec -i -f /etc/haproxy/sqlinject.patterns

However, this does not seems to work, as it does not seem to match anything. Even if I put .* into the pattern file, I get no matches.

There is no syntactical error in the configuration, as haproxy -c returns no warnings or errors. How could I match the urldecoded query string?

P.Péter
  • 569
  • 2
  • 6
  • 24
  • 1
    It seems like the fact that this does **not** throw a configurarion error or warning might be a bug, because it doesn't seem logical to me (but I could be wrong). Consistent with your original style, I would suggest that you try `acl sql_injection url,url_dec -m reg -i -f /etc/haproxy/sqlinject.patterns` or (the way I probably would have written it from scratch without seeing how you are doing it) `acl sql_injection url,url_dec,lower,map_reg(/etc/haproxy/sqlinject.patterns)` (with your regexes written for lower case). – Michael - sqlbot May 19 '18 at 21:21
  • I actually have a nagging sense that there is still something not right about my approaches, either, but can't put my finger in what it might be. – Michael - sqlbot May 19 '18 at 21:28

1 Answers1

0

The variant suggested by @michael-sqlbot seems to be working:

acl sql_injection url,url_dec -m reg -i -f /etc/haproxy/sqlinject.patterns

Thus, the above seems to be a haproxy error, either in configuration verification or interpretation.

P.Péter
  • 569
  • 2
  • 6
  • 24