Безопасность WordPress

WordPress – удивительно успешный проект. За очень короткий срок он превратился из неизвестной платформы для ведения блогов в мощное, продуманное и возможно самое популярное в интернете веб-приложение, собравшее вокруг себя огромное сообщество. Однако все, что становится популярным, привлекает внимание и багоискателей. В доказательство моим словам привожу таблицу количества обнаруженных уязвимостей в WordPress с 2005 года по настоящее время.

Если проследить динамику, то можно заметить тенденцию по увеличению количества найденных багов в WordPress. Усиленное внимание хакеров естественно подтолкнуло разработчиков вплотную заняться вопросами безопасности. Неслучайно в релизе версии 2.5 основные изменения затронули именно эту сторону. В частности, теперь в WordPress’е используется salt при хэшировании паролей. При этом используется библиотека phpass, которая также укорачивает хэши, что в итоге практически лишает взломщика возможности успешно расшифровать хэш, так как брутфорс бесполезен. Пример хэша:

$P$BX4tfgfSatDtQASfYux.0XAg8hQbp00

Следующим нововведением стали более безопасные cookie. В прошлых версиях WP были cookie следующего вида:

wordpressuser_b59c67bf196a4758191e42f76670ceba admin
wordpresspass_b59c67bf196a4758191e42f76670ceba 7e994a44a74c3e7ecace78302bfaeb22

Название каждой куки имело постфикс, однако узнать его было достаточно легко. Нужно было лишь обратиться к wp-pass.php, который возвращал cookiehash в заголовках.
Запрос:

POST /wordpress/wp-pass.php HTTP/1.0
Host: localhost
Connection:close
Content-Length: 20  

post_password=test

Ответ:

HTTP/1.1 200 OK
Date=Sat, 03 May 2008 17:56:56 GMT
Server=Apache/1.3.33 (Win32) PHP/5.1.2
X-Powered-By=PHP/5.1.2
Set-Cookie=wp-postpass_64d798b68407020703a1c0a07dd0793c=deleted; 
expires=Fri, 04-May-2007 17:56:55 GMT; path=/wp22/
Connection=close
Content-Type=text/html

Таким образом, получив cookiehash и хэш пароля админа, можно было залогиниться в админку, не зная исходного пароля. Для этого необходимо было прогнать имеющийся хэш через md5() и вставить его в куку с названием wordpresspass_[cookiehash].

Однако WordPress 2.5 теперь использует такую схему:

user name|expiration_time|HMAC( user name|expiration_time, HMAC(user name|expiration_time, sk))

sk – это SECRET KEY, который необходимо обязательно указывать в wp-config.php наряду с настройками для подключения к базе данных. Он предназначен для того, чтобы привнести рандомность в результаты работы новых криптографических функций. Разработчики WP даже предлагают специальный сервис, который рандомно генерит строку. Таким образом, владельцы последних версий блогов на wordpress (в том числе и я) могут быть уверены, что их веб-интерфейс подвержен минимуму рисков.

Однако есть некоторые слабые места, о которых я хотел бы рассказать. Прежде всего, это незащищенность стандартных папок, так как они закрыты пустыми index.php, но не .htaccess’ами. Более того, такие папки, как wp-content/plugins и wp-content/themes вообще ничем не защищены даже в последних версиях, что делает возможность раскрытия установленных плагинов и даже их версий.

Во-вторых, скрипты WP при прямом выполнении (это вытекает из первого пункта – они не защищены .htaccess’ом), вызывают неинициализированные внутренние функции, так как не проверяют выполняются ли они в контексте WP. Обычно это реализовывается назначением константы в основном скрипте и последующей ее проверкой в остальных скриптах:

<?php 
define("IN_WP",true);
 /**/ 
?> 
<?php 
if(!defined("IN_WP")) die("Not in WP!"); 
?>

Таким образом, это приводит в раскрытию пути в стандартных ошибках PHP, так как в WP нет собственного обработчика ошибок (например такого, как в phpBB 3). Единственное спасение в этой ситуации, как мне кажется, это запрет вывода ошибок. Для этого в корень веб-каталога с WP необходимо вставить файл .htaccess со следующим содержанием:

php_value display_errors 0
php_value error_reporting 0

Третий недочет в безопасности, который я хотел бы выделить – это склонность WP к раскрытию своей версии. Если раньше ее можно было убрать в теме оформления, то WP 2.5 насильно вставляет свою версию между тэгами <head> и </head>. Кроме того, разработчики WP сподвигают людей, которые пишут плагины для платформы, чтобы они также палили версии своих плагинов. Примеров море – просто посмотрите html-код моего блога =)

Еще одна брешь – это слабые пароли админов, так как при установке пароль генерится самим WP и обычно легко может быть расшифрован (пример 0xd3f0s). Как уже было сказано, в WP 2.5.* несмотря на простоту пароля, его вряд ли удастся расшифровать в виду новых криптографических алгоритмов. В админке также появился специальный индикатор, позволяющий оценить сложность пароля (разумеется, его можно увидеть только при создании нового пользователя или изменении своего профиля).

И, наконец, последнее, о чем я хочу сказать касательно безопасности WordPress – это то, что в новой админке, поддерживающей загрузку нескольких файлов одновременно, можно беспрепятственно загрузить php-скрипты, что в предыдущих версиях было запрещено. Чтобы исправить эту досадную оплошность разработчиков создадим еще один .htaccess в папке wp-contents/uploads

RemoveHandler .php .phtml

Также используйте префикс таблиц, отличный от wp_, не забывайте почаще делать бэкап вашей БД, и установите плагин WP Security Scan. Если же вам этого мало, тогда предлагаю ознакомиться с Top10 security-плагинов для WP. На этом все =)