Apache-2.4

ModSecurity SecRule 基於原始瀏覽器 url,而不是內部重寫(index.php、app.php 等)

  • September 14, 2018

我在 Symfony 2 站點上工作,並試圖創建一個 ModSecurity 規則來匹配特定的瀏覽器 URL。IE example.com/results

Symfony 2 在內部使用 .htaccess 中的規則重寫所有對 app.php 的請求,所以當我檢查 ModSecurity 規則中的 REQUEST_URI 時,它被設置為 app.php。我嘗試了任何其他看起來相關的伺服器參數,但都是 app.php 或空白。

有沒有辦法在基於瀏覽器請求的 URL 而不是內部重寫的結果的配置文件中創建 ModSecurity 規則?

CMS 之類的 wordpress 似乎也存在同樣的問題:所有內容都被重寫為 index.php,因此我找不到將 modsec 規則應用於特定路由的任何方法。(我認為由於 WP 如此普遍,我可能可以通過在那裡搜尋相同的問題來找到答案。)

看起來我可以使用伺服器變數THE_REQUEST,根據這個答案:https ://stackoverflow.com/a/27968463/160565

:

我正在使用 mod_rewrite 轉儲THE_REQUEST到 mod_security 規則上方的環境變數中,然後對其進行匹配。

如前所述,THE_REQUEST是 mod_rewrite 使用的 Apache 伺服器變數,而不是 mod_security 變數。mod_security 中直接等效的變數是REQUEST_LINE,即。請求的第一行。這採用字元串的形式,例如:

GET /foo/bar HTTP/1.1

THE_REQUEST(mod_rewrite) 變數在 URL 被重寫時不會改變,而REQUEST_URI(mod_rewrite) 會改變。

但是,我有點驚訝REQUEST_URI(mod_security) 變數正在返回重寫的 URL(也許這與指令的順序或使用 mod_security嵌入有關?),而不是最初請求的 URL,除非您實際使用REQUEST_URI(mod_rewrite) 變數(將其分配給環境變數?)在您的 mod_security 規則中?

就在 mod_security 規則之上…

mod_security 規則可能應該在文件的頂部,如果不是,在任何 mod_rewrite 指令之前。(雖然我不確定訂單是否真的很重要。)

請注意,REQUEST_URI(mod_security) 變數與REQUEST_URI(mod_rewrite) 變數不同,儘管名稱相同。值得注意的是,REQUEST_URI(mod_security) 包含查詢字元串,而REQUEST_URI(mod_rewrite) 不包含。

參考:


更新:

REQUEST_URI(mod_security) 變數正在返回重寫的 URL

您可能在請求中執行 mod_security 規則太晚了,即。錯了phase嗎?要處理請求的URL,您應該REQUEST_URI在第 1 階段或第 2階段(請求)中進行比較。後續階段(即 3 - 5)將針對響應進行處理,這可以解釋為什麼您看到的是重寫的 URL 而不是請求的 URL。

action參數或指令phase中設置。例如:SetDefaultAction

SecDefaultAction "log,pass,phase:2,id:4"
SecRule REQUEST_URI "attack" "phase:1,id:52,t:none,t:urlDecode,t:lowercase,t:normalizePath"

這五個階段是:

  1. 請求標頭 (REQUEST_HEADERS)
  2. 請求正文 (REQUEST_BODY)
  3. 響應標頭 (RESPONSE_HEADERS)
  4. 響應正文 (RESPONSE_BODY)
  5. 記錄 (LOGGING)

從 ModSecurity 版本 v2.7 開始,一些階段編號有別名:

2 - 請求

4 - 響應

5 - 記錄

例子:

SecRule REQUEST_HEADERS:User-Agent "Test" "phase:request,log,deny,id:127"

參考:

引用自:https://serverfault.com/questions/930676