使用mod安全阻止重复http请求

Question

我正在使用mod安全性来查找post参数中的特定值，并在重复进来时阻止请求。我正在使用mod安全用户集合来完成此操作。问题是我的请求长时间运行，因此一个请求可能需要超过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." 

Answer 1

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

正如你所说的，写集合的时候并不能保证，所以即使集合是可靠的（它们不是 - 见下文），你也不应该将它们用于重复检查等绝对事项。对于诸如蛮力或DoS检查之类的事情，它们都可以，例如，在11或12次检查之后停止，而不是10次检查并不是什么大不了的事情。然而，对于绝对检查，如停止重复检查，这里缺乏确定性意味着这是做这个检查的不好的地方。 WAF对我来说应该是一个额外的防御层，而不是你为了使你的应用程序工作（或至少停止破坏）而依赖的东西。对我而言，如果重复请求导致应用程序的事务完整性存在实际问题，那么这些检查属于应用程序而不是WAF。

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

有一个memcache version of ModSecurity created that was created停止使用基于黄昏的SDBM格式，可能已经解决了很多上述问题，但它尚未完成，though it may be part of ModSecurity v3。不过，我仍然不同意WAF是检查这个问题的地方。