Назад | Перейти на главную страницу

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 настолько распространен, что я смогу найти ответ, выполнив поиск той же проблемы там.)

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

Похоже, я могу использовать переменную сервера 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)

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

2 - запрос
4 - ответ
5 - лесозаготовка

Пример:

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

Ссылка: