我正在使用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."
modSecurity确实不是放置此逻辑的好地方。
当您正确地说明何时写藏品时，也无法保证，因此即使集合是可靠的（它们不是 - 参见下文），您也不应将它们用于像重复支票这样的绝对值。对于蛮力或DOS等检查，例如，在11或12支检查后停止而不是10支检查并不是那么大。但是，对于绝对的检查，例如停止重复项，这里缺乏确定性意味着这是进行此检查的不好的地方。对我来说，WAF应该是额外的防御层，而不是您依靠以使应用程序起作用（或至少停止闯入）。对我来说，如果重复的请求导致应用程序的交易完整性引起真正的问题，则这些检查属于应用程序而不是WAF中的。
除此之外，基于磁盘收集的方式在Modsecurity中起作用，会引起很多问题 - 尤其是当多个过程/线程尝试一次访问它们时，这使它们对于持久数据而言是不可靠的，并且可以删除持久数据。当ModSecurity试图自动清理集合时，Modsecurity和Owasp ModSecurity CRS邮件列表中的许多人都在日志文件中出现了错误，因此看到收集文件的成长和增长，直到开始对Apache产生不利影响。通常，我不建议用户收集生产使用量 - 尤其是对于具有任何卷的Web服务器。
创建了Modsecurity的Memcache版本，该版本是使用基于黄昏的SDBM格式停止的，该格式可能已经解决了上述许多问题，但是尚未完成，尽管它可能是ModSecurity V3的一部分。但是，我仍然不同意WAF是检查此问题的地方。