Вопросы Теги

mod_security 403 запрещенный ответ возвращает содержимое домашней страницы с помощью WordPress. Mod_rewrite

Я использую mod_security на разных веб-сайтах, на некоторых WordPress, а на некоторых нет.

Я заметил, что на веб-сайтах, отличных от WordPress, следующее:

https: // test-site .com /? exec = / bin / bash

возвращает запрещенный код ошибки 403 вместе со страницей "запрещенных" ошибок Apache. Ошибка mod_security записывается в журнал.

Однако при установке WordPress, как ни странно, следующее:

https://wordpress-test-site.com/?exec=/bin/bash

возвращает код запрещенной ошибки 403 и записывает ошибку в журнал, однако он отображает содержимое домашней страницы, а не страницу с «запрещенной» ошибкой Apache.

Я отмечаю, что он ведет себя правильно на любой другой странице, кроме домашней. :

https://wordpress-test-site.com/some-page/?exec=/bin/bash

Вышеупомянутое работает должным образом и возвращает страницу с ошибкой Apache.

Я могу только предположить это некоторый конфликт с правилом mod_rewrite WordPress, которое выглядит следующим образом: 

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Что-то мне здесь не хватает? Я не хочу отображать содержимое домашней страницы, когда на главной странице соблюдается правило mod_security.

2
задан 9 October 2020 в 19:33
2 ответа

Я могу только предположить это некоторый конфликт с правилом mod_rewrite

WordPress. Похоже, что на самом деле происходит противоположное . Только когда вы запрашиваете https://wordpress-test-site.com/ , директивы mod_rewrite действительно что-то делают. Когда вы запрашиваете корень документа, директивы mod_rewrite просто не совпадают, и вместо этого запрос переписывается в index.php модулем mod_dir как внутренний подзапрос ( DirectoryIndex документ).

Тем не менее, я ожидал бы такого же поведения и от тестового сайта, не относящегося к WordPress, если у вас есть документ DirectoryIndex ?!

Сказав это, я можно было ожидать, что здесь приоритет будет отдан правилу mod_security?

Чтобы проверить эту теорию, вы можете попробовать изменить свой WordPress .htaccess на следующее: (Я предполагаю, что вы используете .htaccess , поскольку опубликованные директивы mod_rewrite предназначены для использования в контексте каталога .) 

DirectoryIndex disabled

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
#RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ /index.php [L]
</IfModule>

ОБНОВЛЕНИЕ: Обратите внимание на 2 изменения по сравнению с исходными директивами. Шаблон RewriteRule теперь ^ , а не . и директива RewriteCond , которая проверяет, закомментировано ли отображение запроса в каталог.

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

1
ответ дан 4 January 2021 в 08:05

Благодаря @MrWhite в комментариях, на Centos я обнаружил файл с именем /etc/httpd/conf.d/welcome.conf , который содержит: 

<LocationMatch "^/+$">
    Options -Indexes
    ErrorDocument 403 /.noindex.html
</LocationMatch>

Поскольку нет файла с именем .noindex.html сам документ об ошибке 403 вызывал внутреннюю ошибку 404.

Комментирование строк выше устранило проблему.

1
ответ дан 4 January 2021 в 08:05

Теги

Похожие вопросы