0

我正在使用 mod security 来查找 post 参数中的特定值，并在出现重复时阻止请求。我正在使用 mod security 用户集合来做到这一点。问题是我的请求运行时间很长，因此单个请求可能需要 5 分钟以上。我假设的用户集合在第一个请求得到处理之前不会被写入磁盘。如果在执行第一个请求期间，另一个请求使用 post 参数的重复值进入，则第二个请求不会被阻止，因为该集合尚不可用。我需要避免这种情况。我可以在 mod 安全性中跨请求使用基于内存的共享集合吗？还有什么办法吗？片段如下：

SecRule ARGS_NAMES "uploadfilename" "id:400000,phase:2,nolog,setuid:%{ARGS.uploadfilename},initcol:USER=%{ARGS.uploadfilename},setvar:USER.duplicaterequests=+1,expirevar:USER.duplicaterequests=3600" 
SecRule USER:duplicaterequests "@gt 1" "id:400001,phase:2,deny,status:409,msg:'Duplicate Request!'" 

ErrorDocument 409 "<h1>Duplicate request!</h1><p>Looks like this is a duplicate request, if this is not on purpose, your original request is most likely still being processed. If this is on purpose, you'll need to go back, refresh the page, and re-submit the data."
4

1 回答 1

1

ModSecurity 实在不是一个放这个逻辑的好地方。

正如您正确声明的那样，无法保证何时编写集合，因此即使集合在其他方面是可靠的（它们不是 - 见下文），您也不应该将它们用于绝对值，例如重复检查。它们适用于诸如暴力破解或 DoS 检查之类的事情，例如，在 11 次或 12 次检查而不是 10 次检查后停止并不是什么大问题。然而，对于绝对检查，比如停止重复，这里缺乏确定性意味着这是一个不好的地方做这个检查。对我来说，WAF 应该是额外的一层防御，而不是你依赖的东西来使你的应用程序工作（或至少停止破坏）。对我来说，如果重复请求对应用程序的事务完整性造成真正的问题，那么这些检查属于应用程序而不是 WAF。

除此之外，基于磁盘的集合在 ModSecurity 中的工作方式会导致很多问题 - 特别是当多个进程/线程尝试一次访问它们时 - 这使得它们对于持久化数据和删除持久化数据都不可靠。ModSecurity和OWASP ModSecurity CRS邮件列表中的许多人在ModSecurity 尝试自动清理集合时看到日志文件中的错误，因此看到集合文件不断增长，直到它开始对 Apache 产生不利影响。一般来说，我不建议将用户集合用于生产用途——尤其是对于任何容量的 Web 服务器。

创建了一个已创建的 ModSecurity的memcache 版本，该版本停止使用基于黄昏的 SDBM 格式，这可能已经解决了上述许多问题，但尚未完成，尽管它可能是 ModSecurity v3 的一部分。但是，我仍然不同意 WAF 是检查这一点的地方。

于 2017-03-16T10:17:42.147 回答