Pull to refresh

Comments 10

Это будет во второй части, но полезнее было бы добавить как hint к первой:
Когда мы начинаем контролировать аргументы, то функционал админки может пострадать.
Для этого есть небольшое решение:
надо лишь объявить две (по количеству проверок) переменные:
set $wploggedin 0;
set $wppostpass 0;


Следом добавить проверку авторизации средствами nginx:
if ($remote_user ~* "^ВАШ_auth_basic_ЛОГИН_$") {
 set $wploggedin 1;
}

Модифицировать участок, в котором мы проверяем $args как:
if ($args ~* "(attachment_id|media_category|attachment_category|select|eval|duplicate|base64|substring|preg_replace|create_function)") {
   set $wpwrongargs 1;
}


И ниже добавить код:
set $wpresult $wploggedin$wpwrongargs;
			
if ($wpresult = 01)  {
   return 403;
}


Что это даст? В случае работы из той части сайта где требуется авторизация auth_basic (например /wp-admin/) и использовании запрещенных аргументов переменная $wpresult примет значение 11 и ошибки 403 не будет. В случае работы из публичных разделов сайта и обнаружении аргумента из «черного списка» переменная примет значение 01, location ее обработает и выдаст ошибку 403.
Если вы закрываете wp-admin базовой аутентификацией то у вас перестанет работать AJAX, т.к. весь AJAX (включая анонимный) в WordPress работает через файл wp-admin/admin-ajax.php, есть также некоторые вещи, которые работают через wp-admin/admin-post.php.
Спасибо за ваш комментарий, но в базовой версии wordpress я не увидел ни одного ajax обращения в network вкладке моего браузера, которое бы имело код 401 или выдало бы мне окно авторизации.

Единственное, если мне память не изменяет, то когда я поставил плагин MLA (media library assistant) и попробовал его встроенные галереи через [mla-gallery], тут у меня запросило авторизацию.
В принципе, если кто-то хочет позволить AJAX работать, то можно сделать символические ссылки по аналогии с wp-login.php, а в ngx_http_substitutions_filter_module кроме html и xml выбрать еще и обработку JS-скриптов и нужную регулярку с admin-ajax.php на admin-ajax-wp.php (если мы его так назовем).

Я согласен, что это неудобно (заставляет анализировать работу плагинов, редактировать и понимать конфиги и логику nginx, работать по ssh и это не заведется на shared хостингах), но в качестве решения для «белого списка» это идеальный вариант. Для параноиков.
Базовая версия WordPress не использует AJAX на лицевой странице сайта, тем более анонимный. А вот многие темы и плагины используют, это события wp_ajax_* и wp_ajax_nopriv_* (для анонимных запросов). Если вы собираетесь читать и редактировать код плагинов и ядра, пытаться где-то изменить admin-ajax.php на другой файл, то желаю вам удачи, особенно с обновлениями.

Наиболее правильным решением будет открыть доступ к admin-ajax.php и admin-post.php (был еще какой-то файл связанный с TinyMCE на лице, вроде wp-mce-help.php).

Вообще если честно, то блокировка админки WordPress базовой аутентификацией это глупость. Куда надежнее использовать двух факторную аутентификацию, fail2ban или подобные утилиты, HTTPS и конечно же надежные пароли.

Также стоит отметить, что блокировка/удаление/переименование xmlrpc.php это тоже глупость, особенно когда вы попытаетесь воспользоваться внешними инструментами для работы с сайтом, включая официальные мобильные приложения.
Добрый вечер.

Редактировать код я буду лишь в том случае, если ngx_http_substitutions_filter_module будет недостаточно. Но пока его (и моих в regexp) хватает, так что я правлю вывод на frontend'е.

Решение с fail2ban несомненно не затрагивает правку кода, но на мой взгляд куда удобнее закрыть авторизацию wordpress через auth_basic и «зеленый» https («белый» сертификат).

Теперь на счет https в целом и xmlrpc — в статье изначально используются примеры с https и изначально закрыт xmlrpc так как он мне просто не нужен (на чем я акцентирую внимание). Тем более последние проблемы у WP были как раз из-за него. Соответственно если я не использую удаленное ПО для WP, то я его закрываю, дабы не болтался, но не удаляю, так вреда от закрытого не будет.

TinyMCE — у меня стоит advanced версия и если она и делает ajax запросы, то ошибок я не вижу, так как я пишу заметки из админки, в которой я уже авторизован.

Надежные пароли — это несомненно важно, но них я не стал упоминать, так как у параноика по определению они надежные.
У меня была идея делать wget -m -p -k https://example.com/ после каждой публикации, но в этом случае не будет работать встроенный поиск, опросы и не было бы этой статьи.
Конечно можно поставить внешний поиск, можно поставить внешние опросы, но пока нагрузка не велика и уязвимостей, которые могут преодолеть сей барьер, — я в логах не видел.

Скажу, что предшественником WP был немного рабочий вариант на SSI+ngx_http_substitutions_filter_module+bash, где заметки раскладывались по папочкам, оформлялись через ssi и subs nginx'а, а bash генерировал меню и теги.
Я проработал с этим «франкенштейном» месяц, и мои тараканы ликовали! Затем выключил поддомен и положил в ящик на 2 года, потому, что еще не совсем потерянный.

А WP пришел ко мне внезапно, и «голая» 4-ая версия показалась мне тем идеальным минимализмом, который мне нужен. Не как коммерческому ресурсу, а просто %мне%.
И, по причине того, как я поставил в своей священной обители порочный WP, я решил доесть яблоко до конца, и отказался от статической версии сайта и за это моя паранойя предала меня анафеме. И чтобы как-то искупить этот грех, я решил раскаяться и написать о том, что если вы уж и свернули на ту же скользкую дорогу, что и я, то делайте это правильно и не оступайтесь.

После всего случившегося со мной, оглядываться я меньше не стал, но в целом дышится легче.
Если тянет к простому движку на шелле, формирующему сайт из обычных файлов в markdown — посмотрите на werc.cat-v.org/ (на нём работает группа сайтов cat-v.org/).
Спасибо. Нет предполагал, что оно существует да и в таком виде.
Sign up to leave a comment.

Articles