ruby-on-rails – 正则表达式检测基本SQL注入,但不是防止SQL注入

首先,我要说的是,我采取了一些措施来确保SQL注入攻击失败.所有SQL查询值都是通过活动记录预处理语句完成的,所有运算符(如果不是硬编码的)都是通过数字白名单系统完成的.意思是如果有人想通过“ILIKE”进行搜索,他们会传递6,如果他们想通过“=”进行搜索,他们会传递1,等等.

我还定期使用Brakeman和Rails SQL Injection guide来查看代码.

因此,我希望阻止尝试的SQL注入器有三个原因.

>我们得到了很多脚本小子试图破解我们.其中大多数是
已被阻止至少一次,因为我们有一个文件扩展名
白名单系统,当他们试图阻止大部分这些时
请求一个php文件.虽然他们被列入黑名单
第一次,在第二轮他们通常会尝试抛出SQL
注射书给我们.所以我想尽早标记这些小孩
节省带宽,如果真正的演员在哪里攻击我们,那就是
很容易从所有脚本小子中排除它们.
>减慢任何探索我们防御的企图.这不会真的
影响复杂的分布式攻击,但可能会减慢速度
脚本小家伙和超级黑客之间的演员.
>标记所有被阻止的请求并设置我们的日志通知
然后我们的日志服务会通知我们增加我们的服务
安全意识.

目前我的想法是对请求路径和参数运行一个简单的正则表达式匹配,以便标记最明目张胆的SQL注入尝试并将那些ips列入黑名单,所以使用rack-attack.

injection_regex = /SOMEREGEXHERE/

Rack::Attack.blacklist('sql injection blacklist') do |req|
  Rack::Attack::Fail2Ban.filter(req.ip,:maxretry => 5,:findtime => 10.minutes,:bantime => 24.hours) do
    CGI.unescape(req.query_string).match(injection_regex) || req.path.match(injection_regex)
  end
end

我的问题是创建一个正确的标记一个简单的SQL注入尝试的正则表达式,但不会导致常规用户的任何问题.我认为一些误报是可以的,这就是为什么上面的黑名单系统在第一场比赛后没有列入黑名单的原因.

在我的搜索中,我发现了很多关于这个问题的问题,但是它们似乎都在like this one,有人提出使用正则表达式来检测SQL注入的问题,另一个人回答你不应该以这种方式停止SQL注入,那个人问问题是他们不会使用正则表达式来停止,而只是为了检测,然后一堆无用的评论随之而来.

那么,这样的正则表达式是否有可能仅仅作为一种检测手段,最小的误报,或者这样的兔子整体是否值得努力？

'(''|[^'])*'

b(ALTER|CREATE|DELETE|DROP|EXEC(UTE){0,1}|INSERT( +INTO){0,1}|MERGE|SELECT|UPDATE|UNION( +ALL){0,1})b