WordPress — лучшая и прогрессирующая на сегодняшний день CMS, по моему мнению. Однако WordPress обладает некоторыми коварными уязвимостями. Поэтому в этом посте я хочу затронуть одну из уязвимостей, а именно проблему нумерации пользователей в WordPress и подробно расписать как с этим бороться. Также я опишу как игнорировать попытки просканировать пользователей на вашем сайте при взломе…
Введение
Естественно, я не буду здесь подробно описывать приемы взлома сайта на WordPress, но в общем и целом WordPress обладает очень большой косвенной уязвимостью, которую кстати вот уже на протяжении долгого времени разработчики не фиксят, а ей в свою очередь очень часто пользуются. Уязвимость заключается в том, что WordPress по умолчанию присваивает каждому пользователю уникальный ID, который вдобавок еще и может засветиться во front части сайта. Теоретически это позволяет взломщику запустить вредоносный скрипт, который будет сканировать сайт в поисках пользовательских данных, перебирая каждого пользователя по его идентификатору. Например, запрос перечисления типа ?author=1
и до ?author=1000
, может вывести имена пользователей для запрашиваемых id. С таким простым сценарием, атакующий может просканировать ваш сайт и получить список логинов для входа, буквально за несколько секунд.
Общий принцип взлома
При сканировании сайта по идентификаторам пользователей, доступ к пользовательским данным происходит по двум причинам. Во-первых, по постоянной внешней ссылке идет запрос типа ?author=n
(где n равняется любому целому числу), который в свою очередь перенаправляется на постоянную ссылку и она включает в себя логин и имя пользователя. Так например следующие URL запросы:
http://example.com/?author=1 http://example.com/?author=2 http://example.com/?author=3
автоматически перенаправят к WordPress ЧПУ ссылкам типа:
http://example.com/author/admin-user/ http://example.com/author/wordpress-user/ http://example.com/author/some-other-user/
естественно ссылки из примера выше будут отличаться от ваших, но суть процесса я думаю вы поняли.
Вторая причина опять же кроется в том, что в WordPress шаблонах обычно выводятся имена пользователей вместе с их данными. Это можно заметить на архивных страницах и на страницах полного поста, но могут быть и иные варианты в зависимости от WordPress темы.
Стоит ли беспокоиться?
Если вы уверены, что все пользователи на сайте используют надежные пароли, которые регулярно обновляются, то нет ничего страшного и я думаю такой уязвимостью у вас не воспользуются. Но в случае если у вас на сайте несколько и более авторов, пароли которых, я уверен не внушают доверия, то вам стоит побеспокоиться т.к ваш сайт может быть под угрозой, и атакующему не составит труда получить доступ сначала к «самому слабому автору», а затем уже и ко всем остальным и впоследствии ко всему сайту. Поэтому ниже, я опишу несколько простых шагов, которые позволят защитить ваш сайт на WordPress от подобного рода уязвимостей.
Шаг 1: Запрещаем сканирование
Первое, что нужно сделать это всячески блокировать попытки перечисления пользователей у вас на сайте. Это можно сделать одним из двух способов, а можно и всеми двумя :-).
- Добавить блокирующий код в файл functions.php вашей темы;
- Добавить фрагмент кода в файл .htaccess, который лежит в корне сайта.
Давайте теперь рассмотрим каждый из этих методов.
Блокировка перечисления пользователей через functions.php
Что бы препятствовать перечислению пользователей, просто добавьте в файл functions.php следующий код:
if ( ! is_admin() ) { if ( preg_match('/author=([0-9]*)/i', $_SERVER['QUERY_STRING']) ) die(); add_filter( 'redirect_canonical', 'check', 10, 2 ); } function check( $redirect, $request ) { if ( preg_match('/\?author=([0-9]*)(\/*)/i', $request) ) die(); else return $redirect; }
Обязательно после добавления этого отрывка кода проверьте общую работоспособность сайта.
Блокировка перечисления пользователей через .htaccess
Вставьте ниже приведенный отрывок в свой файл .htaccess, который находиться в корне WordPress сайта.
<IfModule mod_rewrite.c> RewriteCond %{QUERY_STRING} ^author=([0-9]*) RewriteRule .* http://example.com/? [L,R=302] </IfModule>
Обратите внимание, что вам необходимо будет заменить домен http://example.com/ на ваш собственный.
Шаг 2: Общая WordPress профилактика
Итак, на данный момент мы добавили необходимый код в functions.php и .htaccess, который будет блокировать все попытки просканировать пользователей сайта. Теперь давайте перейдем ко второму шагу – профилактике. Хочу отметить, что второй шаг носит скорее всего рекомендательный характер и в принципе после первого шага можно дальше ничего не делать, но как говориться лучше перестраховаться.
Под профилактикой подразумевается ручной перебор файлов вашего WordPress шаблона в ходе которого вы должны убедиться, что нигде нет вывода во front логинов и ссылок ваших пользователей. К сожалению, если тема большая, то процесс может занять некоторое время, поэтому ниже я приведу краткий список, где может встречаться код, который отвечает за вывод пользовательской информации.
- Публикации (файлы single-*.php, content-*.php и т.п.);
- Архивы (файлы таксономий и архивов и т.п.);
- Персональная страница автора (файлы author.php и т.п.).
На этом все, надеюсь мой пост поможет сделать ваш сайт, хоть немного безопаснее.