6

首先让我说我是我为确保 SQL 注入攻击失败而采取的措施的知己。所有 SQL 查询值都是通过活动记录准备语句完成的，所有运算符（如果不是硬编码）都是通过数字白名单系统完成的。这意味着如果有人想通过“ILIKE”搜索，他们将传递 6，如果他们想通过“=”搜索，他们将传递 1，等等。

我还定期使用Brakeman和Rails SQL 注入指南来审查代码。

因此，我想阻止尝试的 SQL 注入器还有三个剩余的原因。

  1. 我们有很多脚本小子试图破解我们。其中大多数已经至少被阻止一次，因为我们有一个文件扩展名白名单系统，当他们尝试请求 php 文件时会阻止其中的大部分。虽然他们第一次被列入黑名单，但在第二轮他们通常会试图向我们扔 SQL 注入书。所以我想尽早标记这些小子以节省带宽，如果一个真正的演员在哪里攻击我们，很容易将它们从所有脚本小子中分类出来。
  2. 放慢任何探索我们防御的尝试。这不会真正影响复杂的分布式攻击，但可能会减慢介于脚本小子和超级黑客之间的演员。
  3. 标记所有被阻止的请求并设置日志通知，然后我们的日志服务将通知我们，以提高我们的安全意识。

目前我的想法是针对请求路径和参数运行一个简单的正则表达式匹配，以标记最公然的 SQL 注入尝试并将这些 ip 列入黑名单，所以像这样，使用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 注入尝试的正则表达式，但不会对普通用户造成任何问题。我认为一些误报是可以的，这就是为什么上述黑名单系统在第一场比赛后没有列入黑名单的原因。

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

那么，这样的正则表达式是否有可能仅作为一种检测手段起作用，并且误报率极低，或者这是一个不值得努力的兔子整体吗？

4

1 回答 1

12

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

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
于 2015-09-09T18:24:05.113 回答