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

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

2005 2006 2007 2008
Bugs 11 18 49 34

Если проследить динамику, то можно заметить тенденцию по увеличению количества найденных багов в 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. На этом все =)


8 comments:

  1. mrQwert, 4. Май 2008, 0:23

    Да, к сожилениюпока «хорошей» защитой можно считать только своевременный «бэкап».

     
  2. Roman, 4. Май 2008, 13:08

    Отличная статья ) Поднакопить материала и можно услугу аудита безопасности блогов оказывать — клиентов будет море

     
  3. Raz0r, 5. Май 2008, 15:12

    Roman, такие сервисы уже существуют, вот например один из них:
    http://wp-guard.com/services/

     
  4. Roman, 30. Май 2008, 12:35

    Я знаю, только Дмитрий это указал как одно из возможных дополнительных направлений своей деятельности, основная же работа у него несклько иная )

     
  5. Spm, 4. Июнь 2008, 19:22

    А что-то можно сделать с .htaccess, чтоб как-то сильнее обезопаситься?

     
  6. Цветовод-любитель, 25. Июнь 2008, 20:44

    Пока скрипт будет открыт, будут проблемы с безопасностью. В каждой программе можно найти баги, да и хакерская мысль и смекалка…

     
  7. Juno ISP, 5. Март 2009, 6:52

    Пустых index.html в оригинальном дистрибутиве WP вплоть до 2.7.1 нет, а вещь нужная, лучше сразу озаботиться. В плугах тоже дыр полно, а среди них много популярных, ставших чуть ли не «стандартными».

     
  8. vovasik, 10. Июль 2011, 19:50

    я только одного не допонял у WP три пачки Печенек что ли: обычные wordpress_logged_in_,
    wp-admin wordpress , и wp-content wordpress ?? сли да то за что отвечают wp-content wordpress

     

Write a comment: