用于检测基本SQL注入的Regex，但不是防止SQL注入的方法

Question

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

我还经常使用制动器和Rails SQL注入指南来检查代码。

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

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

目前，我的想法是对请求路径和参数运行一个简单的regex匹配，以便标记最明显的SQL注入尝试，并将那些ips列入黑名单，因此使用机架攻击进行类似的操作。

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注入尝试，但不会给常规用户带来任何问题。我认为一些假阳性是可以的，这就是为什么上面的黑名单系统没有黑名单后，第一次比赛。

在我的搜索中，我发现了许多关于这个主题的问题，但它们似乎都是就像这个，人们问问题使用regex来检测SQL注入，另一个人回答说你不应该以这种方式停止SQL注入，问问题的人回答说他们不会使用regex停止，而仅仅是检测，然后是一堆毫无帮助的评论。

那么，这样的正则表达式是否有可能只作为一种检测手段，以尽可能少的假阳性，还是这是一只兔子的整体，不值得付出这么大的努力？

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