☰

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

tag-icon • tag-icon apache-2.4 mod-rewrite wordpress mod-security
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 настолько распространен, я смогу найти ответ, выполнив поиск по той же проблеме там.)

решение1

Похоже, я могу использовать переменную сервера 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) (назначая ее переменной окружения?) в своем правиле 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. Ведение журнала (ЛЕГИРОВАНИЕ)

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

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

Пример:

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

Ссылка:

решение2

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

Связанный контент