ModSecurity OWASP Core Rule Set - unicode false positive

Question

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

Мы используем 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 \ xce \ xb7 \ xce \ xbb \ xce \ xb9 \ xce \ xbf \ xcf \ x85 \ xcf \ x80 \ xce \ xbf \ xce \ Xbb \ xce \ xb7]

[Pattern матч "(я (:? [\"»\\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 \\\\ ] *? (?: [\\ ... "]

Теперь мы знаем, что это было вызвано требованием 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:/* «(? i: (?: [\ "'´’‘]\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 (и | x? или | div | как | между | и) \ с * [^ \ ш \ s? ]) | (: [^ \ Ш \ s:] \ с * \ d \ W + [^ \ ш \ s] \ s * [\ " '' '' ']) | (?:?.? \ Winformation_schema | table_name \ W)) « » фаза: 2, захват, t: нет, t: urlDecodeUni, block, msg: 'Обнаруживает классический SQL инжекционные зонды 1/2', id: '981242', tag: '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} = {% ТХ.0} ' "

Для решения проблемы мы скорректировали некоторые модели, как [\"' ´’‘] to (\"|'| | \ xc2 \ XB4 | \ XE2 \ x80 \ x99 | \ XE2 \ x80 \ x98), чтобы она соответствовала фактическим комбинации блоков кода UTF-8, которые создают символ. Мы могли бы сделать это для всех 55 правил инжекции SQL в наборе основных правил, но это сложная задача, требующая много времени.

Мы задаемся вопросом, существует ли только некорректная конфигурация с расшифровкой Apache или ModSecurity. Мы знаем все не-ascii и некоторые символы ascii, а также URL, закодированные с помощью% и UTF-8 с помощью веб-браузеров.

Answer 1

Я не думаю, что это проблема декодирования, которая выглядит как ожидаемая для меня, и ваше (досадно подробное) исправление прекрасно, если известно, что приложение, которое вы защищаете, обрабатывает все его URL-адреса как UTF-8. (Это не было бы «правильным» для того, что использовало Windows-1252, например, так как оно снова начнет пропускать ’.)

В качестве альтернативы вы можете полностью удалить фильтрацию смарт-цитат, если вы не пытаясь защитить приложение, которое, как известно, имеет проблемы с SQL-инъекциями, а также плохое управление Unicode. Умные кавычки находятся там, потому что, если приложение сглаживается тогда в ASCII, используя платформенную функцию, которая отображает символы, отличные от ASCII, в ASCII, такие как сопоставленные ‘best fit’ сопоставления Windows, они могут быть преобразованы в одинарные кавычки, тем самым уклоняясь от предыдущего фильтра WAF, который пытался удалите их. (Мне кажется, что правило не включает некоторые другие символы, которые будут сплющены к котировкам, такие как U + 02B9, U + 02BC, U + 02C8, U + 2032 и U + FF07, поэтому, вероятно, он уже не является водонепроницаемым в любых кейс.)

TBH это оценка курса для правил CRS mod_security; особенно для сайтов, которые используют произвольные строки в частях пути, вы получаете лотов ложных срабатываний, а большая часть таких инструментов, как это, настраивает их, чтобы избежать худшего повреждения.

IMO: WAF принципиально ошибочны в принципе (так как невозможно определить, какой вход может составлять атаку против действительного запроса), а CRS по умолчанию более несовершенен, чем большинство. Они полезны в качестве тактической меры для блокирования известных атак с программным обеспечением, которые вы не можете исправить сразу, но в качестве фильтра ввода общего назначения они обычно вызывают больше проблем, чем они исправляют.