Question

首先我要说的是，我已采取措施确保SQL注入攻击失败。所有SQL查询值都是通过活动记录预处理语句完成的，所有运算符（如果不是硬编码的）都是通过数字白名单系统完成的。意思是如果有人想通过＆＃34; ILIKE＆＃34;他们会通过6，如果他们想通过＆＃34; =＆＃34;他们通过1等等。

我还会定期使用Brakeman和Rails SQL Injection guide来审核代码。

因此，我想阻止尝试使用SQL注入器的原因有三个。

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

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

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注入，提出问题的人回答他们不会使用正则表达式来停止，而只是为了检测，然后是一堆无用的评论。

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

Answer 1

此链接应该为您提供开始的模式。

http://larrysteinle.com/2011/02/20/use-regular-expressions-to-detect-sql-code-injection/

文字块

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

SQL语句

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

正则表达式检测基本SQL注入，但不是防止SQL注入的手段

1 个答案: