0

我正在使用mod安全性來查找post參數中的特定值,並在重複進來時阻止請求。我正在使用mod安全用戶集合來完成此操作。問題是我的請求長時間運行,因此一個請求可能需要超過5分鐘。我假設的用戶集合在第一個請求得到處理之前不會寫入磁盤。如果在執行第一個請求期間另一個請求使用post參數的重複值,則第二個請求不會被阻止,因爲集合尚不可用。我需要避免這種情況。我可以使用mod安全性中的請求使用基於內存的共享集合嗎?任何其他方式?下面的代碼片段:使用mod安全阻止重複http請求

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." 

回答

1

ModSecurity實在不是一個放置這種邏輯的好地方。

正如你所說的,寫集合的時候並不能保證,所以即使集合是可靠的(它們不是 - 見下文),你也不應該將它們用於重複檢查等絕對事項。對於諸如蠻力或DoS檢查之類的事情,它們都可以,例如,在11或12次檢查之後停止,而不是10次檢查並不是什麼大不了的事情。然而,對於絕對檢查,如停止重複檢查,這裏缺乏確定性意味着這是做這個檢查的不好的地方。 WAF對我來說應該是一個額外的防禦層,而不是你爲了使你的應用程序工作(或至少停止破壞)而依賴的東西。對我而言,如果重複請求導致應用程序的事務完整性存在實際問題,那麼這些檢查屬於應用程序而不是WAF。

除此之外,集合在ModSecurity中工作的基於磁盤的方式導致了很多問題 - 特別是當多個進程/線程一次嘗試訪問它們時 - 這使得它們對於持久化數據和刪除持久存儲都不可靠數據。當ModSecurity試圖自動清理集合時,ModSecurityOWASP ModSecurity CRSOWASP ModSecurity CRS郵件列表中的許多人都看到了日誌文件中的錯誤,因此看到集合文件的增長和增長直到它開始對Apache產生不利影響。一般來說,我不推薦用於產品使用的用戶集合 - 特別是對於任何卷的Web服務器。

有一個memcache version of ModSecurity created that was created停止使用基於黃昏的SDBM格式,可能已經解決了很多上述問題,但它尚未完成,though it may be part of ModSecurity v3。不過,我仍然不同意WAF是檢查這個問題的地方。