ModSecurity OWASP核心規則集 - unicode誤報

Question

我們運行一些Web服務。

我們使用ModSecurity for Apache webserver和OWASP核心規則集。

由於西裏爾字母和希臘字母，我們在希臘語和俄語請求方面存在問題。

在OWASP CRS的有像

格式規則 「（^ [\」」 ´’‘;]+|[\"'' '';] + $）」

在ModSecurity的登錄有UTF-8 。代碼單元，其中應該是Unicode字符的所有ASCII字母被顯示爲字符應當是

例：

[匹配的數據：\ X85 2 \ xce \ xb7 \ xce \ xbb \ xce \ xb9 \ xce \ xbf \ xcf \ x85 \ xcf \ x80 \ xce 在ARGS中找到：q：163 45 \ xcf \ x83 \ xce \ xbf \ xcf \ x85 \ xce \ xce \ xbd \ xbf \ xcf \ x85 \ xce \ xb7 \ xce \ xbb \ xce \ xb9 \ xce \ xbf \ xcf \ x85 \ xcf \ x80 \ xce \ xbf \ xce \ XBB \ XCE \ XB7]

[圖案匹配 「（I：（：？[\」」 \\xc2\\xb4\\xe2\\x80\\x99\\xe2\\x80\\x98]\\\\s*?(x?or|div|like|between|and)\\\\s*?[\\"' \ XC2 \ XB4 \ XE2 \ X80 \ X99 \ XE2 \ X80 \ X98] \\ d）| （？：\\\\ x（？：23 | 27 | 3d））|（？：^。？['''\\xc2\\xb4\\xe2\\x80\\x99\\xe2\\x80\\x98]$)|(?:(?:^[\\"' \ xc2 \ xb4 \ xe2 \ x80 \ x99 \ xe2 \ x80 \ x98 \\\\ ] *？（？：[\\ ...「]

現在我們知道它是由一個reque st in greek： σουνιουηλιουπολη（雅典的一條街道） 那不是我們的問題。我們可以弄清楚。

問題是，x80是字符'（e2 80 99） 的一部分，x80也是希臘字母的一部分，這就是爲什麼我們得到誤報。

這是觸發的實際規則：

SecRule REQUEST_COOKIES | REQUEST_COOKIES：/ __ UTM/| REQUEST_COOKIES：/ _ pk_ref/| REQUEST_COOKIES_NAMES | ARGS_NAMES | ARGS | XML：/ * 「（？我：（[：[\''´’‘]\s*?(x?or|div|like|between|and)\s*?[\"'''']？\ d）|（？：\\ x（？：23 | 27 | 3d））|（？：^。？['''´’‘]$)|(?:(?:^[\"'''' \\] ？（？：[\ d''´’‘]+|[^\"''''] + [\''´’‘]))+\s*?(?:n?and|x?x?or|div|like|between|and|not|\|\||\&\&)\s*?[\w\"''''] [+ &！@（），.-]）|（？：[^ \ w \ s] \ w + \ s？[| - ]] s *？[\''´’‘]\s*?\w)|(?:@\w+\s+(and|x?or|div|like|between|and)\s*?[\"''''\ d] +）|（？：@ [\ w - ] + \ s（and | x？or | div |像|之間|和）\ S * [^ \ W \ S？ ]）|（：[^ \ W \ S：] \ S * \ d \ W + [^ \ W \ S] \ S * [\「 '`''']）|（：？？？？\ Winformation_schema |'table_name \ W））「 」phase：2，capture，t：none，t：urlDecodeUni，block，msg：'檢測傳統SQL 1/2'，id：'981242'，tag：'OWASP_CRS/WEB_ATTACK/SQL_INJECTION'，logdata：'匹配 數據：％{MATCHED_VAR_NAME}中發現％{TX.0}： ％{MATCHED_VAR}'，嚴重程度：'2'，setvar：'tx.msg =％{規則。 ID} - ％{rule.msg}。 'SETVAR：tx.sql_injection_score = + 1，SETVAR：tx.anomaly_score = +％{tx.critical_anomaly_score}，SETVAR：' TX％{tx.msg} -OWASP_CRS/WEB_ATTACK/SQLI - ％{matched_var_name} =％{TX。0} ' 「

一種解決辦法，我們調整了一些模式，比如[\」' ´’‘] to (\"|'| | \ XC2 \ XB4 | \ XE2 \ X80 \ X99 | \ XE2 \ X80 \ X98），使其符合實際構建角色的UTF-8代碼單元的組合。我們可以爲核心規則集的所有55個SQL注入規則執行此操作，但這是一項耗時的任務。

我們不知道是否有隻是一個Apache或ModSecurity的解碼錯誤配置。我們知道所有非ascii和一些ascii字符以及網頁瀏覽器使用％和UTF-8編碼的URL。

Answer 1

我不認爲這是一個解碼問題，看起來和我預期的一樣，如果知道您正在保護的應用程序將其所有URL輸入視爲UTF-8，那麼您的（煩人的詳細）修復就沒有問題。 （例如，使用Windows-1252的東西不會是'正確的'，因爲它會開始讓’再次通過。）

或者，您可以完全刪除智能報價過濾，假設您不是試圖保護專門知道有SQL注入問題的應用程序以及糟糕的Unicode處理。因爲如果應用程序使用將非ASCII字符映射到ASCII的平臺函數（如Windows誤導的‘best fit’映射）將應用程序平滑到ASCII，則它們可能會轉換爲單引號，從而回避先前嘗試使用的WAF過濾器刪除這些。 （在我看來，這個規則並沒有包括一些其他會被拼湊成引號的字符，比如U + 02B9，U + 02BC，U + 02C8，U + 2032和U + FF07，所以它可能在任何時候都不是水密的情況）

TBH這是意料之中的用於mod_security的CRS規則。特別是對於在路徑部分中使用任意字符串的站點，您會得到大量誤報，其中大部分部署工具正在配置它們以避免最壞的損害。原則上，WAF基本上存在缺陷（因爲無法確定哪些輸入可能構成攻擊與有效請求的關係），而且默認的CRS比大多數缺陷更具有缺陷。它們作爲一種策略措施是非常有用的，它可以阻止已知的針對軟件無法立即修復的軟件的攻擊，但作爲通用輸入過濾器，它們通常會導致比修復更多的問題。