Набор базовых правил ModSecurity OWASP - ложно-положительный юникод

Мы запускаем некоторые веб-сервисы.

Мы используем ModSecurity для веб-сервера Apache с набором основных правил OWASP.

У нас проблемы с запросами на греческом и русском языках из-за кириллицы и греческих букв.

В правилах OWASP CRS есть такие шаблоны, как

"(^[\"" ´’‘;]+|[\"' ' '';]+$)"

В журнале ModSecurity есть единицы кода UTF-8, где должны быть символы Юникода. Все буквы 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\xbd\xce\xb9\xce\xbf\xcf\x85 2 \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)|?)|((:: \\\\ х (23| | 27 3d?):.? ^ [\ "" \\xc2\\xb4\\xe2\\x80\\x99\\xe2\\x80\\x98]$)|(?:(?:^[\\"' \xc2\xb4\xe2\x80\x99\xe2\x80\x98\\\\]*?(?:[\\ ..."]

Теперь мы знаем, что это было вызвано запросом на греческом языке: σουνιου ηλιουπολη (улица в Афинах). Это не наша проблема. Мы можем понять это.

Проблема в том, что x80 является частью символа '(e2 80 99), а x80 также является частью греческого письма, поэтому мы получаем ложный положительный результат.

Фактическое правило, которое было вызвано:

SecRule REQUEST_COOKIES |! REQUEST_COOKIES: / __ utm / |! REQUEST_COOKIES: / _ pk_ref / | REQUEST_COOKIES_NAMES | ARGS_NAMES | ARGS | XML: / * "(? I:(?:[\"') ´’‘]\s*?(x?or|div|like|between|and)\s*?[\"' ' ''] \ D) |?)|((: \\ х (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]+)|(:? @[\ Ш -]+\ с (и | х или | DIV | как | между | и)\ с * [^ \ ш \s])|(??:[^ \ ш \s:]\ с * \d\W+[^\ ш \s]\s* [\ " '' '' '])|(:?.? \Winformation_schema|table_name\W))" " фаза:2, захват,t: нет,t:urlDecodeUni, блок,msg:'Обнаруживает классические SQL-инъекции 1/2',id:'981242', тег:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',logdata:'Соответствующие данные: %{TX.0} найден в%{MATCHED_VAR_NAME}: %{MATCHED_VAR}', серьезность:'2',setvar:'tx.msg=%{rule.id}-%{rule.msg}'SetVar:tx.sql_injection_score=+1, SetVar:tx.anomaly_score=+%{tx.critical_anomaly_score}, SetVar:' ТХ%{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 также являются URL-адресами, закодированными с помощью% и UTF-8 веб-браузерами.