ModSecurity SecRule, основанный на оригинальном URL браузера, а не на внутренней перезаписи (index.php, app.php и т. Д.)

Я работаю над сайтом Symfony 2 и пытаюсь создать правило ModSecurity, соответствующее URL конкретного браузера. IE example.com/results

Symfony 2 внутренне переписывает все запросы в app.php, используя правила в.htaccess, поэтому, когда я проверяю REQUEST_URI в правиле ModSecurity, он устанавливается в app.php. Я пробовал любой другой параметр сервера, который выглядит соответствующим, но все они либо app.php, либо пустые.

Есть ли способ создать правило ModSecurity в файле конфигурации, основанный на URL-адресе, запрошенном браузером, а не на результате внутренней перезаписи?

Похоже, такая же проблема существует и в CMS, как в wordpress: все переписано в index.php, поэтому я не могу найти способ применить правила modsec к определенному маршруту. (Я подумал, что WP настолько распространен, что я мог бы найти ответ, найдя там ту же проблему.)

2 ответа

Решение

Похоже, я могу использовать переменную сервера THE_REQUEST, согласно этому ответу: https://stackoverflow.com/a/27968463/160565

:

Я использую mod_rewrite для дампа THE_REQUEST в переменную окружения чуть выше правил mod_security, а затем сопоставить с этим.

Как указано, THE_REQUEST серверная переменная Apache, используемая mod_rewrite, а не переменная mod_security. Прямой эквивалентной переменной в mod_security является REQUEST_LINEт.е. первая строка запроса. Это принимает форму строки вроде:

GET /foo/bar HTTP/1.1

THE_REQUEST (mod_rewrite) переменная не изменяется при перезаписи URL, тогда как REQUEST_URI (mod_rewrite) делает.

Тем не менее, я немного удивлен, что REQUEST_URI Переменная (mod_security) возвращает переписанный URL (может быть, это связано с упорядочением директив или использованием встроенного mod_security?) вместо первоначально запрошенного URL, если только вы на самом деле не используете REQUEST_URI (mod_rewrite) переменная (присвоение этой переменной env?) в вашем правиле mod_security?

чуть выше правил mod_security...

Правила mod_security, вероятно, должны быть в верхней части вашего файла, если нет, перед любыми директивами mod_rewrite. (Хотя действительно ли порядок имеет значение, я не уверен.)

Обратите внимание, что REQUEST_URI (mod_security) переменная не совпадает с REQUEST_URI (mod_rewrite) переменная, несмотря на то, что названа так же. Следует отметить, что REQUEST_URI (mod_security) содержит строку запроса, тогда как REQUEST_URI (mod_rewrite) нет.

Ссылка:


ОБНОВИТЬ:

... REQUEST_URI (mod_security) переменная возвращает переписанный URL

Возможно, вы выполняете правило mod_security слишком поздно в запросе, т.е. в неправильном phase? Для обработки запрошенного URL вы должны сравнить с REQUEST_URI либо в фазе 1 или 2 (запрос). Последующие этапы (т. Е. 3 - 5) будут обрабатываться в ответе, который может объяснить, почему вы видите переписанный URL, а не запрошенный URL.

phase устанавливается в аргументе действия или SetDefaultAction директивы. Например:

SecDefaultAction "log,pass,phase:2,id:4"
SecRule REQUEST_URI "attack" "phase:1,id:52,t:none,t:urlDecode,t:lowercase,t:normalizePath"

Пять фаз:

  1. Заголовки запроса (REQUEST_HEADERS)
  2. Тело запроса (REQUEST_BODY)
  3. Заголовки ответа (RESPONSE_HEADERS)
  4. Тело ответа (RESPONSE_BODY)
  5. Логирование (LOGGING)

Начиная с версии v2.7 ModSecurity существуют псевдонимы для некоторых номеров фаз:

2 - запрос
4 - ответ
5 - регистрация

Пример:

SecRule REQUEST_HEADERS:User-Agent "Test" "phase:request,log,deny,id:127"

Ссылка:

Похоже, я могу использовать серверную переменную THE_REQUEST, согласно этому ответу: https://stackoverflow.com/a/27968463/160565

Другие вопросы по тегам