ModSecurity OWASP Core Rule Set - ложное срабатывание Unicode

У нас есть несколько веб-сервисов.

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

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

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

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

В журнале 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 \ 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: (?: [\" '_ 2_ \ xc2 \ xb4 \ xe2 \ x80 \ x99 \ xe2 \ x80 \ x98]? \\ d) | (?: \\\\ x (?: 23 | 27 | 3d)) | (?: ^.? [\ "'_ 3_ \ 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: (?: [\" '_ 4_´' ']? \ D ?: \\ x (?: 23 | 27 | 3d)) | (?: ^.? [\ "'_ 5_´' '\\] ? (?: [\ d \"' _ 6_´ '' ] + [\ "'_ 7_´' '] [+ &! @ (), .-]) | (?: [^ \ W \ s] \ w + \ s? [| -] \ s * ? [\ "'_ 8_´' '\ d] +) | (?: @ [\ W -] + \ s (и | x? Или | 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:' Соответствующие данные:% {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.% {tx.msg} -OWASP_CRS / WEB_ATTACK / SQLI-% {matched_var_name} =% {tx.0} '"

В качестве обходного пути мы скорректировали некоторые шаблоны, такие как [\ "'_ 9_ | \ xc2 \ xb4 | \ xe2 \ x80 \ x99 | \ xe2 \ x80 \ x98), чтобы они соответствовали фактическим комбинациям UTF-8 блоки кода, которые создают символ.Мы могли бы сделать это для всех 55 правил внедрения SQL из основного набора правил, но это трудоемкая задача.

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


person Marco Wagner    schedule 16.08.2016    source источник
comment
Список рассылки OWASP CRS (lists.owasp.org/mailman/ listinfo /) вполне подходит для такого рода вещей. Отправьте ответ здесь, если они помогут вам в этом разобраться.   -  person Barry Pollard    schedule 16.08.2016


Ответы (1)


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

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

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

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

person bobince    schedule 21.08.2016