Безопасный логин в WordPress с использованием nginx
Лишние плагины не нужны
WordPress, начиная с версии 2.6, имеет улучшенную поддержку работы с HTTPS.
У администратора есть две возможности:
- Использование HTTPS для работы в панели управления (
wp-admin). - Использование HTTPS только для входа в систему.
Первое достигается путём добавления строки
в wp-config.php, второе — путём добавления строки
Добавляем одну из этих двух строк в wp-config.php и проблема решена? Но в действительности всё не так, как на самом деле 
У специалистов по информационной безопасности существует негласное правило, по которому HTML-форма, передающая данные на HTTPS-страницу, должна также находиться на HTTPS-странице. Связано это с тем, что соединение, по которому передаются данные, может прослушиваться. В случае обычного HTTP-соединения злоумышленник может модифицировать передаваемую от сервера форму, заменив https на http, что приведёт к тому, что форма будет отправлена по обычному (не зашифрованному) соединению, и злоумышленник сможет перехватить всю ценную информацию. Усугубляется это всё тем, что пользователь не может сказать, куда передаётся форма, не открыв исходный код страницы.
Для предотвращения подобного безобразия сама форма должны находиться на HTTPS-страницы: злоумышленник не сможет изменить данные, передаваемые по зашифрованному каналу.
Казалось бы, при чём тут Лужков WordPress? Во-первых, WordPress даже при включённом FORCE_SSL_LOGIN не перенаправляет пользователя с http://.../wp-login.php на https://.../wp-login.php. А во-вторых, WordPress — это не только платформа для блоггинга, это еще и CMS, на основе которой делаются всякие магазины и даже целые панели управления сайтами (да, я принимал участие в создании одной из таких панелей). Иными словами, платформы, где успешный перехват логина и пароля может привести к очень печальным последствиям.
Какие есть варианты? Самый простой — написать простой плагин, который сделает перенаправление с HTTP на HTTPS для wp-login.php. Но лишний PHP-код скорости работы не прибавляет, а потому не наш метод. Тем более, когда всё можно сделать на уровне сервера.
Рассмотрим на примере nginx.
В nginx есть две возможности настроить HTTPS-сервер. Первая (она же наиболее часто используемая) — это задание отдельного виртуального хоста для HTTP- и HTTPS-версий сайта. Что-то вида
listen 80;
server_name example.com;
#...
}
server {
listen 443;
server_name example.com;
ssl on;
#...
}
В этом случае всё просто: нужно добавить следующие строки в виртуальный хост, отвечающий за HTTPS:
rewrite .* https://example.com/wp-login.php break;
}
Вторая возможность — задать HTTP- и HTTPS-версию сайта в одном виртуальном хосте:
listen 80;
listen 443 ssl;
server_name example.com;
# Ни в коем случае нельзя задавать директиву ssl on
#...
}
В этом случае добавляемый код будет сложнее:
if ($ssl_protocol = "") {
rewrite .* https://example.com/wp-login.php break;
}
fastcgi_pass ...;
fastcgi_param SCRIPT_FILENAME /path/to/blog/wp-login.php;
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_NAME /wp-login.php;
}
Очевидно, что в директивах fastcgi_xxx нужно указать свои пути.
После этого nginx будет автоматически перенаправлять посетителя с http://.../wp-login.php на https://.../wp-login.php. Таким образом и форма, и адрес отправления формы будут находиться на защищённых страницах.
Связанные записи
Автор: Vladimir; опубликовано в: WordPress, Безопасность; метки: HTTPS, nginx, SSL, WordPress, безопасностьДек
2009
Меня зовут Владимир, я программист-фрилансер, специализирующийся на Web-программировании и програмировании под Linux.
По совместительству занимаюсь администрированием LAMP/LNMP-серверов и техническим переводом.
