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"
Пять фаз:
- Заголовки запроса (REQUEST_HEADERS)
- Тело запроса (REQUEST_BODY)
- Заголовки ответа (RESPONSE_HEADERS)
- Тело ответа (RESPONSE_BODY)
- Логирование (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