☰

Htacess Helicon APE 誤報 403 失敗

tag-icon • tag-icon iis .htaccess mod-rewrite
Htacess Helicon APE 誤報 403 失敗

web.config我一直在使用，而不是用於我的重寫規則螺旋APE用於模擬 Apache 的.htaccess功能。

我有一個大型通用.htaccess文件，作為功能的一部分應用於整個伺服器，以限制對傳遞命令（如聯合、刪除等）的存取。

但是，我遇到了一個問題，其中一行程式碼建立了誤報並阻止對其他正確 URL 的存取。

失敗的 URL 是：http://example.com/union-contracts

在 中使用以下命令web.config，所有遺失的 URL 都會被推送到index.php。

   <httpErrors errorMode="Custom" existingResponse="Replace">
        <remove statusCode="404" subStatusCode="-1" />
        <error statusCode="404" path="/index.php" responseMode="ExecuteURL" />
    </httpErrors>

傳回 403 的 htaccess 規則

RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC]
RewriteRule . - [F,L]

最終，我想繼續阻止聯合，例如，我只需要修改誤報行。請注意，我也不希望在我的規則-contracts中進行硬編碼。.htaccess

在記住 URL 是如何產生的之後，我能夠在 XAMPP 中的 htaccess 中複製該問題。

在網站的訪客一側，當存取 URL 時，伺服器會產生 404 錯誤。我將 URL 過濾到最後一部分，然後根據該字串檢查資料庫，看看它是否與保存的 URL 匹配，如果是，我不會將該 404 傳遞給瀏覽器，只有當 URL 可以時它才會傳遞。找不到。

當 IIS 產生 404 錯誤時，URL 變成：

index.php?404;http://example.com:80/union-contracts

但它不會以這種格式傳遞到瀏覽器。

答案1

我在評論中表達了我的擔憂，認為肯定有“其他事情”發生，但無論如何...

為一開始就不應該（讀作：「不能」）觸發的規則編寫一個例外是很困難的——這完全是猜測工作。畢竟，為什麼會例外感到榮幸嗎？

由於幾個“重大”原因，該規則應該已經避免了給定的請求：

  1. 該請求不包含查詢字串。
  2. 條件中的正規表示式 (條件模式) 與 URL 的任何部分都不符（即使它位於查詢字串中）。

考慮到上面的#2，正規表示式已經包含了足夠的異常，無法匹配給定的請求，那麼我們如何實現「另一個」異常呢？

您可以修改條件模式為了避免連字號 ( -) 跟在單字「union」後面，請使用負前瞻。例如：

(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union(?!-)|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode)

因此，上面的內容匹配Xunion，但不匹配Xunion-，其中X是第一個字元序列中的一個交替組（即(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00)）。

或者，當連字號跟在以下任何關鍵字後面時：

(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode)(?!-)

（更新：以下兩個建議可能行不通，因為這些指令似乎只被處理後IIS 已經重寫了 URL。此時 URL 路徑只是/index.php，而不是/union-contracts。

或者，修改RewriteRule，使其在 URL 路徑開頭時不匹配/union-（儘管這可能為規則試圖阻止的 XSS 嘗試提供後門）。例如：

RewriteRule !^/?union- - [F]

（至少在 Apache 上，使用L該標誌時不需要該標誌- 這是隱含的。）F

或者，您可以在以下位置建立另一個規則頂部/union-，在現有規則之前，當請求以開頭且沒有查詢字串的 URL 時，會建立一個例外（儘管如果相信其他規則，這似乎是矛盾的）。例如：

RewriteCond %{QUERY_STRING} ^$
RewriteRule ^/?union- - [L]

但是，如果文件中稍後有其他規則需要以某種方式重寫 URL，這可能會「破壞」請求 - 因為這些不會發生。

我假設 Helicon-APE/mod_rewrite 在類似目錄的上下文（例如，.htaccess樣式語法而不是伺服器或者虛擬主機情境)?儘管這不應該影響上面的指令，但確實如此。

更新：當 IIS 產生 404 錯誤時，URL 變成：

index.php?404;http://example.com:80/union-contracts

是啊！那個網址將要被原來的狀況束縛。所以，似乎 mod_rewrite 指令已被處理後IIS「重寫」了web.config！這確實使這些「安全」指令有些多餘甚至不正確，因為它們是應該根據客戶端的初始請求運行。和....

我將 URL 過濾到最後一部分，然後根據該字串檢查資料庫以查看它是否與保存的 URL 匹配

由於您正在主動解析 URL 並過濾掉您需要的部分，那麼這些「安全」檢查似乎至少對於這些「404」請求來說是多餘的。 （事實上，根據可能直接請求的真實文件（即非 404 請求），這種性質的惡意查詢字串是否真的會對任何 URL 構成安全威脅？）

上面的兩個建議修改了正規表示式狀態排除「union」關鍵字後面有連字號的情況，或者任何關鍵字，仍然適用於此，似乎可以解決眼前的問題。

您也可以在遇到表單的 URL 時index.php?404;（即它被 IIS 重寫之後）中止所有檢查。 （我假設您所有的 mod_rewrite 指令都是類似的「安全」檢查？）

例如，將以下內容新增至頂部.htaccess腳本的前現有指令：

RewriteCond %{QUERY_STRING} ^404;
RewriteRule ^/?index\.php - [L]

/index.php?404;......當遇到表單的 URL 時，這應該可以防止任何進一步的處理。 （因為您無論如何都會在腳本中解析 URL。）

相關內容