Необычная защита от PHP Include. Отправляем письма активации

“Сайты банков ломают ради денег, Пентагон — ради шпионажа, а мой проект никому не нужен”, — к сожалению, именно так полагает большинство владельцев личных блогов, интернет-визиток, виртуальных представительств небольших компаний. О том, как защитить сайт, задумываются лишь единицы, а зря. В современных реалиях абсолютно любая площадка, независимо от типа или популярности, представляет интерес в глазах хакеров. Кому и для чего может понадобиться ваш ресурс? Давайте разбираться:
1. Шалости скрипткиддис. Жаргонизм обозначает начинающих хакеров, которые делают первые шаги на “темной стороне”. Обзаведясь несколькими инструментами, или написав пару собственных программ, они горят желанием проверить их работоспособность на первой попавшейся жертве, и выбирают, как правило, наиболее легкие (слабо защищённые и не обновленные CMS) цели.
2. Черное SEO. Услуги нечистых на руку оптимизаторов все еще в ходу — размещение скрытых ссылок в коде проектов, имеющих тИЦ более 10, по прежнему практикуется. И, в первую очередь, под удар попадают ресурсы на движках с открытым исходным кодом (Joomla, Drupal, OpenCart и так далее).
3. Построение бот-нета. Защита WordPress с помощью htaccess и плагинов актуальна еще и потому, что абсолютно любой ресурс может быть использован для создания зомби-сети, используемой в ходе DDoS-атак, рассылки спама и т.д.
4. Сопутствующий ущерб. Наконец, атаковать могут не вас — основной целью будет являться хостинг, а сайт послужит лишь в качестве одной большой уязвимости IT-инфраструктуры провайдера. Разумеется, его судьба будет безразлична хакерам.

Последствия взлома могут быть самые неприятные: утрата контента, или ресурса в целом, пессимизация в выдаче поисковых систем, потеря аудитории из-за надписи “Сайт может угрожать безопасности компьютера или мобильного устройства”, и даже риск стать фигурантом уголовного дела в том случае, если на базе вашего веб-ресурса были совершены противоправные действия.

А значит, можно с уверенностью утверждать — вопросы безопасности затрагивают абсолютно каждого веб-мастера. И если ими пренебречь, все усилия по поисковому продвижению (а это — деньги и драгоценное время) способны в одночасье пойти прахом. Проблема весьма актуальна, поэтому я решил начать серию статей, посвященных сетевым угрозам и методам борьбы с ними. В трех выпусках будет рассмотрена популярная CMS система — Вордпресс.

Методы защиты сайта на WordPress

Один из наиболее примитивных способов взлома — брутфорс. Дословно термин переводится как “грубая сила”, и означает получение пары логин/пароль методом полного перебора возможных вариантов. Зачастую брутфорсеры стараются облегчить свою жизнь, воспользовавшись погрешностями в настройках движка и сервера — это помогает им, например, узнать имя учетной записи, что существенно сокращает количество комбинаций. Именно об устранении этих уязвимостей, а также о методах борьбы с попытками несанкционированного доступа и пойдет речь.

1. Используйте уникальный логин администратора

По умолчанию система предлагает создать пользователя с именем admin. Однако в целях защиты сайта на WordPress лучше всего использовать логин, состоящий из набора случайных букв и цифр. На действующем ресурсе имя администрататора можно без особых проблем сменить, используя один из двух способов:

Через админку. Зайдите в раздел “Пользователи”, нажмите кнопку “Добавить нового” и создайте учетную запись. В поле “Роль” выберите “Администратор” и подтвердите операцию. Затем перелогиньтесь от имени только что созданной учетки, вернитесь в раздел “Пользователи”, выберите “admin” и нажмите “Удалить”. В открывшемся окне выставьте радиокнопку в позицию “Связать все содержимое” и выберите нового администратора из выпадающего списка, а затем нажмите на “Подтвердить удаление”.
. Используя phpMyAdmin. Гораздо проще осуществить эту же процедуру через панель управления базами данных. Выберите необходимую БД, найдите таблицу wp_users, отыщите строчку “admin” (ID=1), нажмите на “Изменить” и впишите желаемое имя.

2. Заведите специальный аккаунт для публикаций

Если “не светить” администратора, это обеспечит дополнительную защиту. Создайте отдельную учетную запись для размещения статей и привяжите к ней все опубликованные ранее материалы способом, описанным в пункте 1. Далее добавляйте информацию и общайтесь с читателями только с нового аккаунта.

3. Поставьте сложный пароль

Соблюдайте общепринятые рекомендации: длина пароля должна составлять не менее 10 символов, он должен быть уникальным и состоять из случайной последовательности прописных и заглавных букв, цифр и специальных знаков.
Ни в коем случае нельзя:
. составлять пароль из значимых фраз
. использовать любые фактические данные (дата рождения, девичья фамилия, номер банковского счета, текущий год…)
Это исключит риск подбора кодовой фразы по словарю, а также существенно увеличит время, требующееся для брутфорса. Так, взлом последовательности из 10-ти символов, состоящей только из строчных букв и цифр (hki458p1fa), займет 10 дней машинного времени для одного ПК, но стоит добавить заглавные буквы и дополнительные знаки (Nv6$3PZ~w1), как этот период увеличится до 526 лет, гарантируя практически абсолютную защиту WordPress. Придумывать и запоминать подобные пароли достаточно сложно, особенно если вы курируете несколько проектов. Поэтому, для их генерации и хранения лучше использовать специальные менеджеры, например — распространяемый бесплатно KeePassX, либо обычный тестовый документ (лучше, если он будет запакован в архив с паролем).

4. Смените пароль для базы данных

Перечисленные выше правила справедливы и для безопасности кода доступа к MySQL. Ведь именно там содержится весь контент, а также хэш секретной фразы админа. Если вы уже используете слабый пароль, стоит озаботиться тем, чтобы его поменять. Делается это следующим образом:

1. Зайдите в панель управления phpMyAdmin
2. Откройте вкладку “Пользователи” и выберите владельца БД
3. Нажмите на “Редактирование привилегий”
4. Найдите графу “Изменить пароль” и впишите новую секретную последовательность в соответствующие поля
5. Сохраните изменения, нажав на “Ок”

Теперь осталось отредактировать wp-config.php, иначе Вордпресс не сможет подключиться к базе данных. Найдите строчку define(‘DB_PASSWORD’, ‘password’); и впишите новый пароль вместо слова password. Обратите внимание: поскольку знак (‘) применяется для обособления SQL-команд, его не следует использовать в составе секретной фразы.

5. Регулярно обновляйте пароли

Их стоит менять по крайней мере раз в полгода. Внеочередная же смена кодовых фраз должна ОБЯЗАТЕЛЬНО осуществляться после:

Передачи данных для аутентификации третьим лицам (программистам, системным администраторам, оптимизаторам, и другим специалистам, даже если они работают в штате хостинговой компании)
. входа на веб-ресурс с чужого компьютера (в гостях, в интернет-кафе)
. авторизации с оборудования, которое могло быть скомпрометировано (машина, зараженная вирусом)

6. Не забудьте поменять секретные ключи для куки

Они располагаются в файле wp-config.php. Всего их 8:

define ("AUTH_KEY" , "unique key" ) ; define ("SECURE_AUTH_KEY" , "unique key" ) ; define ("LOGGED_IN_KEY" , "unique key" ) ; define ("NONCE_KEY" , "unique key" ) ; define ("AUTH_SALT" , "unique key" ) ; define ("SECURE_AUTH_SALT" , "unique key" ) ; define ("LOGGED_IN_SALT" , "unique key" ) ; define ("NONCE_SALT" , "unique key" ) ;

define("AUTH_KEY", "unique key"); define("SECURE_AUTH_KEY", "unique key"); define("LOGGED_IN_KEY", "unique key"); define("NONCE_KEY", "unique key"); define("AUTH_SALT", "unique key"); define("SECURE_AUTH_SALT", "unique key"); define("LOGGED_IN_SALT", "unique key"); define("NONCE_SALT", "unique key");

Как нетрудно догадаться по названиям переменных, ключи отвечают за шифрование файлов куки (известный жаргнозим: cookie — печенье, salt — соль, кормим хакеров соленым печеньем), которые используются для того, чтобы сайт “запомнил” ваш компьютер после авторизации. Суть в том, что даже если злоумышленник получит в свое распоряжение хэш админского пароля, он не сможет сгенерировать куки, необходимые для доступа к сайту без перечисленных секретных фраз.

В целях повышения безопасности, последовательности символов по умолчанию необходимо заменить на уникальные сразу после развертывания CMS. Для удобства разработчики создали веб-генератор, расположенный по адресу www.api.wordpress.org/secret-key/1.1/salt/ — при заходе вам покажутся ключи, а если обновить страницу, то комбинации актуализируются.

7. Двойная авторизация для админки

Htaccess позволяет дополнительно защитить сайт Вордпресс, путем добавления аутентификации на уровне сервера. Код будет выглядеть следующим образом:

< Files wp- login. php> # Задаем базовый тип аутентификации - это означает, что при попытке # обращения к указанному каталогу или файлу будет запрошен пароль: AuthType basic # Вписываем текст, который будет отображаться в заголовке формы: AuthName "Identify yourself" # Указываем путь к файлу, содержащему кодовую фразу: AuthUserFile "/home/сайт/.htpasswd" # Указываем, что при обращении к файлу wp-login.php необходимо ввести пароль: Require valid- user # Запрещаем доступ к файлу.htpasswd третьим лицам: < Files . htpasswd> order allow, deny deny from all

# Выбираем файл скрипта авторизации: # Задаем базовый тип аутентификации - это означает, что при попытке # обращения к указанному каталогу или файлу будет запрошен пароль: AuthType basic # Вписываем текст, который будет отображаться в заголовке формы: AuthName "Identify yourself" # Указываем путь к файлу, содержащему кодовую фразу: AuthUserFile "/home/сайт/.htpasswd" # Указываем, что при обращении к файлу wp-login.php необходимо ввести пароль: Require valid-user # Запрещаем доступ к файлу.htpasswd третьим лицам: order allow,deny deny from all

Заодно неплохо бы позаботиться о безопасности самого htaccess. Строго говоря, такая директива должна быть прописана в основных настройках хостинга, но учитывая безалаберность некоторых провайдеров, стоит перестраховаться:

Вместо “login” подставляем желаемое имя. Осталось сгенерировать сам пароль, а также зашифровать его, ведь хранить подобные данные в открытом виде — непозволительная роскошь. Для этого существует масса сервисов, но лучше написать нужный скрипт самостоятельно. Делается это следующим образом:

1) Создайте в блокноте файл с расширением.php, например, crypt.php
2) Внесите туда код, подставив вместо слова “Password” придуманный вами пароль:

3) Сохраните файл и загрузите в корневую директорию
4) Перейдите по ссылке имя_сайта.ru/crypt.php — на экране появится хэш пароля
5) Сохраните это значение в файле.htpasswd, и загрузите его в корневой каталог, а crypt.php удалите

Последний штрих — запрет просмотра содержимого директории веб-ресурса. Достаточно добавить в htaccess единственную строчку:

Options All - Indexes

Options All -Indexes

Это делается для того, чтобы хакеры не могли узнать, какие именно файлы лежат в каталогах проекта. На многих хостингах данная директива уже внесена в настройки сервера, но если этот момент упущен из виду, стоит прописать ее самостоятельно.

8. Установите капчу

Использование капчи позволит отсечь если не всех, то, по крайней мере, большую часть ботов-брутфорсеров, а заодно . Каталог плагинов для защиты сайта на WordPress предлагает множество вариантов. Помимо подключения фирменного решения от Google, большой интерес представляет Captcha by BestWebSoft смешанного (графика и текст) типа, в основе которой лежат математические действия. Независимость от сервисов, наглядность и приемлемый уровень сложности делает модуль одним из лучших.

Настройка не представляет особых проблем. Вкладка “Базовые” позволяет выбрать, где следует отображать капчу, а также указать заголовок и символ для пометки полей, обязательных к заполнению.

Раздел “Расширенные” обеспечивает возможность создания собственных сообщений об ошибках, а также активации дополнительных пакетов изображений, чтобы еще больше усложнить жизнь ботам.

Еще одна полезная возможность — встроенный белый список IP-адресов, для которых капча отображаться не будет.

Результатом установки и активации плагина станет появление формы на странице авторизации:

9. Измените адрес админки

Рассказывая о том, как защитить сайт на WordPress, стоит упомянуть более радикальный, но и более сложный способ — изменение URL страницы авторизации на уровне скриптов. Процедура осуществляется в несколько этапов:

1. Переименуйте файл wp-login.php. Используйте случайную последовательность строчных латинских букв, цифры и тире. Например: abc-123.php
2. В получившемся файле найдите все упоминания wp-login.php и замените их на новое название.
3. Для корректной работы сайта замену необходимо проделать также в: wp-activate.php, general-template.php, post-template.php, functions.php, class-wp-customize-manager.php, general-template.php, link-template.php, admin-bar.php, post.php, pluggable.php, ms-functions.php, canonical.php, functions.wp-scripts.php, wp-signup.php, my-sites.php, schema.php, ru_RU.po

После этих манипуляций админка будет располагаться по адресу сайт/abc-123.php. Доступ к новому файлу следует ограничить и защитить паролем так, как указано выше. Кроме того, можно ввести в заблуждение потенциальных хакеров, создав подложный файл wp-login.php, и также установив для него пароль.

Еще более простой вариант — использование дополнения «Rename wp-login.php». После установки плагина для защиты сайта в меню “Настройки” — > “Постоянные ссылки” появится новое поле:

10. Укажите IP админа

Дополнительную безопасность можно обеспечить в том случае, если у вас имеется статический IP-адрес. Запретив доступ к wp-login.php с любого другого компьютера, кроме собственного, вы значительно усложните жизнь взломщикам:

< Files wp- login. php> order deny, allow deny from all allow from 127. 0. 0. 1, 127. 0. 02 #Через запятую указываем ваши IP-адреса

order deny,allow deny from all allow from 127.0.0.1, 127.0.02 #Через запятую указываем ваши IP-адреса

11. Отключите ошибки авторизации

При переборе паролей злоумышленнику очень пригодится информация о том, что введенные данные оказались неверны. Такие сообщения выводятся при каждой неудачной попытке входа, причем WordPress также сообщает, что именно было введено неверно, логин или пароль. Чтобы от них избавиться, достаточно добавить в functions.php всего одну строчку:

add_filter("login_errors" , create_function ("$a" , "return null;" ) ) ;

add_filter("login_errors",create_function("$a", "return null;"));

Для этого выберите в админке “Внешний вид” — > “Редактор” — > “Функции темы”. Прописывать код необходимо после открывающего тега

12. Используйте защищенное соединение.

Для шифрования трафика между компьютером пользователя и веб-сервером существует протокол https, использование которого исключает возможность перехвата важных данных, в нашем случае — идентификационных. Чтобы его активировать, сперва требуется приобрести SSL-сертификат, выполняющий сразу две функции: удостоверение подлинности веб-ресурса и шифрование передаваемой информации. Получить его можно в специализированных центрах, или у ряда регистраторов доменных имен. Для некоммерческих целей вполне достаточно обзавестись бесплатным сертификатом начального уровня (такие предлагает компания www.startssl.com). Что же касается процесса установки, как правило он подробно описан в справочном разделе хостера.

Заполучив SSL-сертифкат, необходимо настроить переадресацию административной части веб-ресурса на защищенное соединение. В случае Вордпресс это делается с помощью следующей конструкции:

< IfModule mod_rewrite. c> Options + FollowSymlinks RewriteEngine On RewriteCond % { HTTPS} = off RewriteCond % { REQUEST_URI} =/ wp- login. php RewriteRule (.* ) https:

Options +FollowSymlinks RewriteEngine On RewriteCond %{HTTPS} =off RewriteCond %{REQUEST_URI} =/wp-login.php RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Также форсировать использование сертификатов SSL можно на уровне движка. Для этого откройте файл wp-config.php и добавьте после

define ("FORCE_SSL_ADMIN" , true ) ;

define("FORCE_SSL_ADMIN", true);

Помимо этого, можно установить глобальную переадресацию с http на https. Для новых сайтов такой подход является оптимальным, учитывая, что Google поощряет защищенные проекты, отдавая им некоторый приоритет в поисковой выдаче:

< IfModule mod_rewrite. c> Options + FollowSymlinks RewriteEngine on RewriteCond % { HTTPS} = off RewriteRule ^(.* ) $ https: //%{HTTP_HOST}%{REQUEST_URI}

Options +FollowSymlinks RewriteEngine on RewriteCond %{HTTPS} =off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}

13. Блокируйте злоумышленников

При обнаружении подозрительной активности с определенных IP стоит заблокировать для них доступ к сайту. Делается это по аналогии с предыдущим способом. Разница в том, что директивы прописываются для проекта в целом, а перечисляем мы адреса тех, кого хотим забанить:

Order Allow,Deny Allow from all Deny from 127.0.0.1, 127.0.02 #Указываем нежелательные IP

Метод надежен, однако неэффективен. Во-первых, каким-то образом необходимо фиксировать запросы брутфорсеров и отделять их от добропорядочных посетителей. Во-вторых, при массированной атаке вы попросту не сможете отслеживать и вбивать IP хакеров и ботов вручную. Данный способ хорош только если администратор располагает достоверным “черным списком” адресов.

В остальных случаях можно воспользоваться плагином для защиты сайта на WordPress под названием WP Cerber. Данное решение является абсолютно бесплатным, при этом предлагая весьма внушительный набор инструментов, призванных предотвратить взлом CMS. Установить его можно непосредственно из админки.

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

Галочку напротив “Блокировать IP при любом запросе wp-login.php” стоит ставить в том случае, если вы поменяете адрес админки способом, описанным ранее.

Для этих целей можно использовать и собственный инструмент WP Cerber:

Режим плагина для защиты сайта “Цитадель” также не нуждается в дополнительной настройке. Он предназначен для “консервации” проекта при массированной брутфорс-атаке. Галочку напротив “Записывать попытки входа в файл” лучше снять — это поможет исключить дополнительную нагрузку на сервер.

Вкладка “Списки доступа” служит для создания “черного” и “белого” списка IP (если у вас есть статический адрес, обязательно внесите его в перечень доверенных), а раздел “Инструменты” позволяет осуществлять импорт и экспорт внесенных ранее настроек. Впрочем, эти возможности не нуждаются в отдельном рассмотрении.

14. Переместите конфигурационный файл

Как мы выяснили выше, в wp-config.php хранятся такие критически важные данные, как логин и пароль для доступа к MySQL, а также ключи API. Следующий шаг, вроде бы, очевиден — защита WordPress через htaccess с помощью ограничения доступа к файлу:

< Files wp- config. php> Order allow, deny Deny from all

Order allow,deny Deny from all

Однако есть и более надежный метод. У WordPress имеется весьма интересная особенность, о которой мало кто знает. Движок допускает размещение конфигурационного файла на один уровень выше корневой директории..php можно перенести в каталог сайт. В этом случае файл станет вообще недоступен через Интернет, при этом, содержащаяся в нем информация будет все так же считываться CMS.

15. Добавьте проверку REFERER

Метод, хорошо зарекомендовавший себя при защите WordPress от спама, поможет и в случае противостояния брутфорсерам. Ведь перебор паролей — отнюдь не ручная работа: для этих целей используются специализированные программы. А значит, включив проверку заголовков во входящих запросах, можно отсечь “пришедших из ниоткуда” ботов с пустым HTTP REFERER:

< IfModule mod_rewrite. c> RewriteEngine On RewriteCond % { REQUEST_METHOD} POST RewriteCond % { REQUEST_URI} . (wp- comments- post| wp- login) \. php* RewriteCond % { HTTP_REFERER} !.* tekseo. su.* [ OR] RewriteCond % { HTTP_USER_AGENT} ^$ RewriteRule (.* ) http: //%{REMOTE_ADDR}/$1

RewriteEngine On RewriteCond %{REQUEST_METHOD} POST RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php* RewriteCond %{HTTP_REFERER} !.*сайт.* RewriteCond %{HTTP_USER_AGENT} ^$ RewriteRule (.*) http://%{REMOTE_ADDR}/$1

16. Защитите XML-RPC

Начиная с версии 3.5 из Вордпресс пропала возможность отключения протокола вызова удаленных процедур XML-RPC. В основном он нужен для взаимодействия с мобильными приложениями, однако подобный функционал требуется далеко не каждому. При этом, xmlrpc.php активно используется для проведения DDoS-атак, являясь ахиллесовой пятой всего проекта.

Кроме того, хакеры додумались использовать XML-RPC для брутфорса. Использование метода wp.getUsersBlogs позволяет осуществлять перебор учетных данных гораздо быстрее, нежели через форму админки. Так как многие вызовы XML-RPC требуют авторизации, запрос вида:

< methodCall> < methodName> wp. getUsersBlogs < params>< param>< value>< string> admin < param>< value>< string> 12345

wp.getUsersBlogs admin 12345

приведет к тому, что движок сообщит, является ли переданная комбинация верной. Чтобы избавиться от этой напасти, необходимо полностью отключить протокол. Сделать это можно несколькими способами:

1) Заблокировав доступ к файлу xmlrpc.php через htaccess

require_once(ABSPATH . "wp-settings.php");

необходимо прописать

function remove_x_pingback($headers) { unset($headers["X-Pingback"]); return $headers; } add_filter("wp_headers", "remove_x_pingback");

4) Используя плагин Control XML-RPC publishing, возвращающий в “Настройки” -> “Написание” соответствующую опцию:

Обратите внимание: дополнение отключает протокол сразу после активации, а в настройках вы можете включить его, проставив галочку в соответствующий чекбокс.

17. Отслеживайте брутфорс-атаки

Напоследок стоит упомянуть об интересном плагине для логирования попыток взлома — Authentication and xmlrpc log writer. Хотя тот же WP Cerber имеет встроенные средства мониторинга, данный модуль будет все равно полезен, особенно тем, кому нужны возможности описанного выше протокола. AX LogWriter умеет отслеживать брутфорс через xmlrpc.php, благодаря чему можно оценить степень угрозы и целесообразности полного отказа от использования его возможностей. Наконец, тем, кто вовсе не занимался безопасностью своего проекта, плагин для защиты сайта откроет глаза на важность перечисленных мероприятий.

Использование AX LogWriter не представляет сложностей. После установки в меню админки появится соответствующий раздел, где можно внести все необходимые изменения:

В поле “Error Type” выберите способ сохранения. Поддерживается запись в системный лог, лог сервера Апач, а также возможность создания кастомного файла. В последнем случае для него можно также настроить имя (Custom Error Log Name) и директорию (Custom Error Log Path). Это открывает широкие возможности для системного администратора — например, решение можно использовать вместе с fail2ban. Также не забудьте выбрать подходящий часовой пояс в графе Timezone.

Кастомный лог можно просматривать непосредственно из админки на странице Custom Log Viewer:

Подытожим:

Перечисленные методы помогут существенно повысить безопасность вашего ресурса и уберечь его от ботов-брутфорсеров, сетевых хулиганов и практикующихся скрипткиддис. Однако все, что описано выше — лишь верхушка айсберга. В арсенале злоумышленников есть и куда более изощренные методы. И уже в следующей статье мы поговорим о том, как защититься от настоящих хакеров, использующих различные уязвимости движка и серверного программного обеспечения. Как и в данном материале, помимо общих “правил гигиены” будут рассмотрены ключевые настройки CMS, способы модификации кода, а также наиболее актуальные плагины.

Все программные продукты для защиты PHP-скриптов подразделяются на две категории: требующие установки на сервер дополнительных модулей и работающие с обычной конфигурацией web-серверов. Первые более надежны в плане безопасности, так как переводят PHP-скрипты из текстового вида в специальный двоичный-код, но требуют доступа к серверу с правами администратора. Вторые могут работать практически на всех хостингах с поддержкой PHP, в том числе и бесплатных, но не представляют большой сложности для взлома. В отдельную подгруппу можно выделить исходного кода, не использующие шифрование или сжатие.

Защиты на уровне сервера:

Zend Encoder / Zend SafeGuard Suite - наиболее популярная коммерческая защита, модули для поддержки Zend обычно установлены на всех платных хостингах. Zend предоставляет привязку скриптов к доменам и ip, установку времени триальной работы скриптов и мощную обфускацию. Поддерживаются все операционные системы. В публичном доступе имеется несколько вариантов утилит для снятия Zend"а, все они представляют собой модифицированный PHP 4-й и 5-й версии. Старые версии Zend"а снимаются без проблем, в последних возникают сложности из-за обфускации исходного кода.

Новая, активно развивающаяся коммерческая защита. На уровне собственных API предоставляет взаимодействие с защищаемыми скриптами, поддерживаются операционные системы Windows и Linux. Вследствие малой распространенности не устанавливается на обычных виртуальных хостингах, но вполне может быть установлена пользователями на выделенных серверах. Публичных декодеров нет.

Коммерческая защита, практически не встречается, на вирутальных хостингах не устанавливается. Позволяет устаналивать триальный срок работы скриптов с проверкой даты по внешним серверам точного времени, делать привязку защищаемых скриптов к серверам, ip-адресу, MAC-адресу сетевой карты, причем эти данные используются для расшифровки. Поддерживаются все операционные системы. Публичных декодеров нет.

phpSHIELD . Прототип SourceGuardian for PHP. После слияния двух разработчиков перестал развиваться как самостоятельный продукт. Основной функционал тот же самый, публичных декодеров нет.

ionCube PHP Encoder . Второй по популярности коммерческий продукт для защиты скриптов. После появления публичных декодеров для Zend стал все чаще использоваться и устанавливаться на виртуальных хостингах. Позволяет шифровать не только скрипты, но и шаблоны, xml-документы, изображения, бинарные файлы. Привязывает защищенные файлы к серверам, есть мощный обфускатор, поддерживаются все операционные системы. Публичных декодеров нет, но в некоторых случаях снимается deZender"ом.

PHTML Encoder . Малораспространенная коммерческая система защиты, предоставляет обычный функционал для продуктов такого типа, работает под всеми операционными системами. За отдельную плату можно приобрести исходные коды защиты и модифицировать их под свои нужды. Публичных декодеров нет.

DWebEncoder . Экзотическая защита под Windows, предназначенная для создания скриптовых презентаций и каталогов на компакт-дисках. В установленном виде представляет собой что-то типа самостоятельного web-сервера, на котором исполняются закодированные php-скрипты. Публичных декодеров нет.

PHP Compact . Защита скорее теоретическая, чем практическая. Разрабатывалась на одном из отечественных форумов, но похоже дальше авторских релизов дело не продвинулось. Декодеров нет, впрочем как и защищенных скриптов.

Дополнение с открытым кодом к старинным php-акселераторам Turck MMCache и eAccelerator. Переводит скрипты в байт-код с целью повышения скорости их выполнения. Есть версии модулей под Windows и Linux. Публичных декодеров нет, но возможно открытый код проекта как-то поможет в изучении.

Защиты на уровне исходного кода:

PHP LockIt! . Популярная коммерческая защита, встречается очень часто, в основном на скриптах зарубежных разработчиков. Позволяет устанавливать триальный срок работы скриптов, привязку к доменам и ip-адресам, сжимает скрипты штатными средствами php (gzinflate). Единственная сложность - хороший обфускатор. Различные версии защиты отличаются только модификацией модуля распаковки. Легко снимается как в ручном, так и в автоматическом режиме. Без обфускатора снимается в точности до исходного кода, с обфускатором требует дополнительной обработки.

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

PHPCipher . Защита представляет собой он-лайн сервис. На сайт загружается архив с вашими скриптами и обратно скачивается уже защищенный. Платная лицензия позволяет подписывать защищенные скрипты своими данными и использовать для коммерческих целей. Бесплатная лицензия допускает использование только для личных нужд. Сама защита представляет собой защищенный Zend"ом php-модуль, который подключается к защищенным скриптам. После deZend"а модуля защиты и получения из него всех необходимых констант снимается полностью до исходного кода. Функции обфускатора нет.

ByteRun Protector for PHP . Коммерческий продукт, в зависимости от типа лицензии позволяет защищать скрипты как на уровне сервера, так и на уровне исходного кода. Серверная защита со стандартными возможностями, ничего особенного нет. Защита на уровне скриптов снимается очень легко автоматически и вручную. Публичного декодера на серверную версию нет.

Очень популярная у отечественных разработчиков защита. Представляет собой сильно замусоренный пустым кодом модуль защиты, который подключается через include к защищенным скриптам. Алгоритм декодирования очень простой, не вызывает никаких сложностей в ручном и автоматическом снятии. Во всех случаях снимается полностью до исходного кода, функции обфускатора нет. Есть небольшие особенности для частных случаев декодирования, но здесь они описаны не будут.

CodeLock . Еще одна популярная защита, отличный пример безграмотного программирования. Представляет собой приложение на php, позволяет кодировать как сами скрипты, так и результат их работы в браузере средствами javascript. Скрипты можно защищать паролем, но из-за бездарной реализации пароль легко узнать даже не снимая навесную защиту. Модуль защиты представляет собой замусоренный пустым кодом php-скрипт, который подключается к защищаемым скриптам. Алгоритм защиты очень простой, снимается полностью до исходного кода. Функции обфускации нет.

TrueBug PHP Encoder , с недавнего времени TrueBug PHP Obfuscator & Encoder. Очень интересный протектор для исследования. До версии 1.0.2 использовались стандартные средства php для gzip-компрессии, начиная с версии 1.0.3 авторами был разработан собственный алгоритм сжатия. В новом продукте TrueBug PHP Obfuscator & Encoder добавлена функция обфускации и оптимизации исходного кода. Единственное слабое место защиты - неизменный алгоритм декодирования скриптов, но сам алгоритм меняется для каждой версии защиты. После разбора защиты снимается легко в точности до исходного кода, естественно при условии что не был использован обфускатор.

Zorex PHP CryptZ . Защита, как и CodeLock, представляет собой приложение на php, для его работы требуется база MySQL. Модуль защиты - подключаемый скрипт на php, зашифрованный в несколько слоев. После разбора алгоритма снимается очень легко в точности до исходного кода. Функции обфускатора нет.

Free PHP Encoder . Бесплатный он-лайновый сервис для кодирования php-скриптов. Модуль защиты представляет собой подключаемый php-скрипт, накрытый Zend"ом, который надо скачать с сайта. После снятия Zend"а и разбора алгоритма защита легко снимается полностью до исходного кода. Алгоритм защиты неизменный, функции обфускатора нет.

Скрипт на php, кодирование примитивное, стандартный base64. Большего внимания не заслуживает и практического интереса не представляет.

Давайте с вами подумаем кто такой хакер? Хакер — это не взломщик! Люди часто путают эти понятия. Хакер — это прежде всего человек с нестандартным мышлением, и в этом его сила, если можно так сказать.

Чтобы успешно противостоять хакеру, нужно также научится нестандартно мыслить. Как говорится, клин клином вышибают.

Сегодня я предложу вам очень необычный способ защитится от атак типа php include. Подходит он конечно далеко не всем. И если чесно защищает он не от самой атаки, а от ее обнаружения. Заинтриговал?

Как ищется инклуд…

Давайте сначала разберемся как именно взломщик пытается обнаружить уязвимость.

Выглядит это следующим образом. Злоумышленник модифицирует все входящие параметры по очереди, предполагая что данные этих параметров попадают в функцию инклуда. Ну или если по-простому пытается «приинклудить» файлы. И для того чтобы определить есть ли уязвимость или нет, ему необходимо приинклудить какой нибудь файл на целевой системе (приикнулдилось — уязвимость есть, нет — уязвимости нет).

Естественно если злоумышленник действует извне, то он не знает структуру расположения каталогов и файлов, и не может приинклудить любой файл, так как не будет знать пути к нему. Но бывают такие файлы, которые всегда существуют в системе, и к которым есть всегда права на чтение. Для Linux — это /etc/passwd, а для Windows — пусть будет C:\boot.ini. Но впрочем Windows нас мало интересует, поэтому дальше мы будем говорить про passwd

/etc/passwd

Наверное вы натыкались в своих логах на больше количество записей вида:

Action=../etc/passwd%00
?action=../../etc/passwd%00
?action=../../../etc/passwd%00
?action=../../../../etc/passwd%00
?action=../../../../../etc/passwd%00
?do=../etc/passwd%00
?do=../../etc/passwd%00
?do=../../../etc/passwd%00
?do=../../../../etc/passwd%00
?do=../../../../../etc/passwd%00
?id=../etc/passwd%00
?id=../../etc/passwd%00
?id=../../../etc/passwd%00
?id=../../../../etc/passwd%00
?id=../../../../../etc/passwd%00

Если да — то знайте, у вас пытались найти php include (ну или возможность чтения произвольных файлов, но нас сейчас это не интересует). Так вот, если один из ваших параметров не обрабатывается должным образом и попадает в функцию include() , то тогда бы файл /etc/passwd приинклудился, содержимое бы его интерпретировалось как php скрипт, и так как он не содержит тегов php кода, он бы вывелся в браузер в неизменном виде. Это бы и послужило бы взломщику «маркером» наличия уязвимости.

К чему я это пишу, к тому что при поисках инклудов, злоумышленник обязательно (гарантирую что в 90% случаев) будет пытаться приинклудить файл /etc/passwd .

Защищайтесь, сударь!

Наверное вы сейчас подумали: «Он что, хочет предложить обычный WAF и фильтровать пакеты по наличию /etc/passwd в них?». Нет. Это стандартный способ. Это пример того как мыслит обычный человек.

Давайте проявим немного фантазии. Почему бы нам просто не добавить немножко php кода в содержимое файла passwd? И если вдруг у злоумышленника получится его приинклудить, то наш php код выполнится. (Считаете бредом? — загляните в заключение)

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

Но как же добавить php код в /etc/passwd ведь его синтаксис жестко регламентирован? У каждого пользователя есть поле «comment» — описание пользователя, туда можно вписать все что угодно (за исключением двоеточия, разумеется). Поэтому берем и добавляем пользователя в систему с нужным нам комментарием. После этого /etc/passwd будет содержать вот такую строчку

root:x:0:0:Superuser:/:
daemon:*:1:5::/:/sbin/sh
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
securityuser:*:1001:1001::/:

Ну а в подключаемом скрипте уже выполняем нужные вам действия — баним пользователя, блокируем обращение, уведомляем администратора.

В итоге у нас получилась своебразная ловушка, которая сможет защитить ваш сайт от взлома.

Заключение

Да, я вполне отдаю себе отчет, что все написанное выше похоже на бред. И прекрасно понимаю, что никто это на практике использовать не будет. Но писал я не для этого. Писал я для того чтобы показать пример нестандартного подхода в области защиты.

Спасибо за внимание =)

Когда дело доходит до безопасности приложений, важно заботиться не только о железе и операционной системе, но и о написании защищённых скриптов. В данной статье вы узнаете, как обеспечить безопасность вашего приложения и сделать его менее уязвимым. Ниже приведён список мер, которые помогут вам защитить ваше приложение от всевозможных атак:

1. Валидация входящих данных
2. Защита от XSS атак
3. Защита от CSRF атак
4. Предотвращение SQL инъекций
5. Защита файловой системы
6. Защита данных сессии
7. Обработка ошибок
8. Защита подключаемых файлов

Валидация входящих данных

Во время проектирования приложения, вам нужно стремиться защитить его от “плохих” входящих данных. Правило, которому нужно следовать, звучит примерно так: “Никогда не верьте тому, что ввёл пользователь”. Несмотря на то что большинство пользователей не представляют угрозы, всегда есть вероятность того, что кто-то захочет хакнуть ваш сайт, используя “плохие” данные, вводимые через формы или адресную строку. Если вы всегда проверяете и фильтруете входящие данные, то у вас неплохие шансы написать безопасное приложение.

Всегда проверяйте ваши данные в PHP скриптах. Если же вы используете JavaScript для валидации данных, то в любой момент злоумышленник может отключить его в своём браузере. В таком случае ваше приложение в опасности. Никто не против JavaScript валидации, но для хорошей защиты вам необходимо перепроверять данные в PHP скриптах.

Защита от XSS атак

Межсайтовый скриптинг или XSS атака - это атака, основанная на внедрении кода на потенциально уязвимых страницах. Опасность в том, что вредоносный код может быть введён через формы, а затем отображён в браузере.

Предположим, на вашем сайте есть форма для ввода комментариев, которые сразу же отображаются после добавления. Злоумышленник может ввести комментарий, содержащий JavaScript код. После отправки формы, данные переправляются на сервер и заносятся в базу данных. После этого данные извлекаются из базы и новый комментарий отображается на HTML странице, включая и внедрённый JavaScript код. Он может перенаправлять пользователя на какую-то вредоносную страницу или на фишинговый сайт.

Для защиты ваших приложений, пропускайте входящие данные через функцию strip_tags() , которая удалит все присутствующие теги. При отображении данных в браузере, применяйте функцию htmlentities() .

Защита от CSRF атак

Следующий вид атаки, который мы рассмотрим, это CSRF атака или подделка межсайтовых запросов. Атакующий использует различные трюки для получения конфиденциальной информации или совершения сделки без ведома жертвы. В основном это происходит на плохо защищённых сайтах, где бизнес логика строится на работе GET запросов.

Вообще говоря, GET запросы идемпотентны. Идемпотентность, в данном контексте, означает, что доступ к одной и той же странице может быть осуществлён сколько угодно раз без всякого стороннего вмешательства. Именно поэтому GET запросы должны использоваться только для получения доступа к информации, но ни в коем случае не для осуществления различного рода транзакций.

Следующий простой пример показывает как незащищённый сайт может подвергнуться CSRF атаке:

Предположим, что Боб хочет совершить CSRF атаку над Алисой. Он сформировал специальный url адрес и отправил его Алисе на e-mail:

Посети мой сайт!

Если Алиса авторизована на сайте example.com и пройдёт по данной ссылке, то с её счёта на счёт Боба будет переведено $1000. В качестве альтернативы Боб может отправить и изображение, а в атрибуте src внести “плохой” адрес.

Браузер не сможет отобразить данное изображение, так как его не существует, однако запрос будет совершён без ведома и участия Алисы.

В качестве предотвращения подобного рода атак, используйте только POST запросы к процессам, предназначенным для изменения информации в базе данных. Не используйте $_REQUEST . Пользуйтесь $_GET -ом для обработки GET параметров, и $_POST для извлечения POST параметров.

В качестве дополнительных мер можно сгенерировать какой-то уникальный токен и прикреплять его к каждому POST запросу. При входе пользователя в систему, можно генерировать случайный токен и записывать его в сессию. Поскольку все формы выводятся пользователю, данный токен нужно записывать в скрытое поле. В бизнес логике приложения должен быть предусмотрен функционал, который будет проверять токен из форм и токен, хранящийся в сессии.

Предотвращение SQL инъекций

Для выполнения запросов к базе данных следует использовать PDO. Благодаря параметризированным запросам и подготовленным выражениям, вы можете свести на нет угрозу SQL инъекций.

Давайте рассмотрим следующий пример:

В коде, представленном выше, мы отправляем запрос в метод prepare() , включая именные параметры: :name и:age . Таким образом, запрос пре-компилируется для дальнейшей подстановки данных. При вызове метода execute() , запрос полностью формируется и выполняется. Если вы пользуетесь подобной техникой, то все попытки злоумышленника осуществить SQL инъекцию будут сведены к нулю.

Защита файловой системы

Как ответственный разработчик, вы должны всегда писать такой код, который не подставит под риск вашу файловую систему. Давайте рассмотрим код, которой отдаёт на скачку файл в зависимости от данных, переданных пользователем.

Данный скрипт очень опасен, так как из-за него можно получить доступ к любому каталогу, который доступен из файла со скриптом: к каталогу с сессиями, системным папкам и многому другому.

Защита данных сессии

По умолчанию вся информация сессий записывается в каталог temp. Если вы пользуетесь виртуальным хостингом, кто-то помимо вас может написать скрипт и считать данные сессий. Поэтому остерегайтесь хранения паролей или номеров кредиток в сессиях.

Если же всё-таки вам необходимо хранить подобные данные в сессии, то лучшей мерой будет шифрование. Это до конца не решает проблему, так как зашифрованные данные не на 100% безопасны, однако хранимая информация будет нечитабельной. Также вам стоит подумать о том, что данные сессии можно хранить в другом месте, таком, как база данных. В PHP есть специальный метод session_set_save_handler() , который позволит вам хранить данные сессий по-своему.

Начиная с PHP 5.4 вы можете передать объект типа SessionHandlerInterface в session_set_save_handler() .

Обработка ошибок

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

На публичном сервере вам необходимо отключить такие опции, как display_errors и display_start_up_errors , а вот такие опции как error_reporting и log_errors , должны быть активны, чтоб все ошибки, возникшие у пользователей, записывались в логи.

Также вы можете использовать “ set_error_handler ” для определения своего собственного обработчика ошибок. Однако тут могут возникнуть ограничения, ведь собственный обработчик уступает родному PHP механизму. Ошибки E_CORE_ERROR , E_STRICT или E_COMPILER_ERROR не смогут быть отловлены в том же файле, где и определённый обработчик. Более того, ошибки, которые могут возникнуть в самом обработчике также не смогут быть отловлены.

Для более элегантного способа отлавливания исключений, потенциально опасный код нужно помещать в блок try/catch. Все собственные исключения должны быть объектами классов или подклассов Exception . Если исключения и были выброшены, то в блоке try/catch их можно обработать.

Защита подключаемых файлов

Часто в PHP скриптах происходит подгрузка других файлов, таких как подключение к базе и многих других. Некоторые разработчики дают таким файлам расширение.inc. Такие файлы по умолчанию PHP не парсит. Если обратиться к ним по адресу напрямую, пользователь сможет увидеть текст данного файла. Если же хакеру удастся получить доступ к файлу хранящиму данные подключение к базе, то в последствии он может получить доступ ко всем данным вашего приложения. Так что всегда используйте расширение.php для подгружаемых файлов и храните их там, куда нет прямого пользовательского доступа.

Итог

Если вы будете следовать перечисленным 8 правилам, то это в значительной мере позволит усилить устойчивость вашего приложения к различного рода атакам. Не доверяйте данным, введённым пользователями, защищайте ваши файлы и базу данных.

Создаем собственную страницу регистрации для мультисайта взамен стандартной wp-signup.php .

В обычной установке WordPress страницу регистрации (авторизации, сброса пароля) выводит файл wp-login.php .

• /wp-login.php - авторизация
• /wp-login.php?action=register - регистрация
• /wp-login.php?action=lostpassword - сброс пароля

Для мультисайта в wp-login.php есть отдельные условия. Так, при переходе по ссылке /wp-login.php?action=register на мультисайте, WordPress сделает редирект на страницу /wp-signup.php . Во многих темах страница выглядит не очень привлекательно, поэтому мы сделаем свою собственную.

Основной сайт сети

По умолчанию, WordPress открывает страницу регистрации (wp-signup.php) на основном домене (сайте) сети. Тем не менее, можно сделать отдельную страницу регистрации для каждого сайта сети, даже если у них разные темы. Мы будем рассматривать случай, когда на всех сайтах сети есть своя собственная страница регистрации, но используется одинаковая тема и сайты различаются лишь языком. Если используются разные темы, потребуется написать больше кода.

functions.php?

Нет. Имя этого файла, кажется, упоминается в любой статье про WordPress. В нашем случае, с учетом того, что функционал регистрации рассчитан на несколько сайтов, имеет смысл вынести его в MU-плагины, которые загружаются при открытии любого сайта.

Лирическое отступление

Стоит отметить, что MU-плагины загружаются раньше обычных плагинов и до полной загрузки ядра WordPress, поэтому вызов некоторых функций может привести к фатальным ошибкам в PHP. Подобная «ранняя» загрузка имеет и свои плюсы. Скажем внутри любой темы нельзя цепляться к некоторым экшенам, которые срабатывают еще до загрузки файла functions.php из темы. Примером этого могут служить экшены из плагина Jetpack вида jetpack_module_loaded_related-posts (related-posts - название модуля) с помощью которых возможно отслеживать активность модулей в Jetpack. К этому экшену невозможно «прицепиться» из файла темы, потому что экшен уже сработал до загрузки темы - плагины загружаются раньше тем. Взглянуть на общую картинку порядка загрузки WordPress можно на странице Action Reference в кодексе .

Порядок в файлах

MU-плагины могут содержать любое количество файлов и любую стуктуру, которая покажется вам логичной. Я придерживаюсь примерно такой иерархии:

|-mu-plugins |-|-load.php |-|-|-selena-network |-|-|-|-signup |-|-|-|-|-plugin.php |-|-|-|-|-... |-|-|-|-jetpack |-|-|-|-|-plugin.php

В файле load.php подключаются все необходимые «плагины» для нашей сети:

// Load Traslates for all addons load_muplugin_textdomain ("selena_network", "/selena-network/languages/"); // Network Signup require WPMU_PLUGIN_DIR . "/selena-network/signup/plugin.php"; // Another plugins // require WPMU_PLUGIN_DIR ...

Внутри папки selena-network хранятся папки плагинов, в каждой есть свой plugin.php , которые мы и подключаем в load.php . Это дает гибкость и возможность быстро отключать и включать некоторые вещи.

Адрес страницы регистрации

Чтобы указать адрес страницы регистрации, используется фильтр wp_signup_location . Его можно найти внутри файла wp-login.php и именно он отвечает за редирект на wp-signup.php .

Case "register" : if (is_multisite()) { wp_redirect(apply_filters("wp_signup_location", network_site_url("wp-signup.php"))); exit;

Добавим свою функцию в mu-plugins/selena-network/signup/plugin.php , которая будет отдавать адрес страницы регистрации на текущем сайте:

Function selena_network_signup_page ($url) { return home_url () . "/signup/"; } add_filter ("wp_signup_location", "selena_network_signup_page", 99);

selena_network - префикс, который я использую в именах всех функций внутри MU-плагинов на своем сайте для избежания коллизий, его следует заменить на свой собственный уникальный префикс. Приоритет добавления фильтра 99, потому что некоторые плагины, например bbPress и BuddyPress могут перезаписать этот адрес на свой собственный (MU-плагины загружаются раньше, чем обычные плагины, см. выше). Обратите внимание, что используется home_url() , вместо network_site_url() , чтобы оставить посетителя на том же домене. В качестве адреса можно использовать любой URL.

Создание страницы

Теперь создадим страницу с адресом site.com/signup/ через обычный интерфейс, а в папке дочерней темы шаблон для нашей новой страницы - page-signup.php . Вместо слова «signup» можно использовать уникальный ID.

Внутри нового шаблона необходимо выполнить вызов функции selena_network_signup_main() , которая будет выводить форму регистрации.

Стоит заметить, что весь процесс с шаблонами не обязателен и вместо этого можно создать свой шорткод, который будет также вызывать функцию selena_network_signup_main() .

wp-signup.php и wp-activate.php

Теперь займемся созданием функции, которая будет выводить форму регистрации. Для этого скопируем файлы wp-signup.php и wp-activate.php из корня WordPress в mu-plugings/selena-network/signup/ (и не забываем их подключить внутри mu-plugins/selena-network/signup/plugin.php). Дальнейшие манипуляции с файлами крайне сложно и долго описывать, поэтому прийдется сделать их самостоятельно. Я лишь опишу что именно надо сделать и опубликую исходные файлы своего проекта:

1. В начале файла удалить все require , вызов функций и прочий код вне функций.
2. Переименовать все функции, добавив к именам уникальные префиксы.
3. Нижнюю часть кода wp-signup.php обернуть в функцию selena_network_signup_main и в ее самом начале написать global $active_signup; .
4. Заменить верстку на свою собственную в нужных местах.

Внутри wp-activate.php необходимо сделать примерно тоже самое:

1. Удалить весь код вне функций, обернуть верстку в отдельную функцию.
2. Изменить верстку в местах, где это необходимо.

Файл wp-activate.php отвечает за страницу активации аккаунта. Как и со страницей регистрации для нее необходимо создать отдельный шаблон, внутри которого вызывать функцию из файла wp-activate.php .

Отправляем письма активации

Страница регистрации отправляет посетителю письмо со ссылкой на активацию аккаунта. По умолчанию этим занимается функция wpmu_signup_user_notification() из файла ms-functions.php . Ее функционал можно заимствовать для своей функции. Причина, по которой необходимо отказаться от использования этой функции - она отправляет ссылку активации аккаунта с wp-activate.php . «Выключить» же эту функцию можно с помощью фильтра wpmu_signup_user_notification отдавая по нему false (если этого не cделать, письмо активации будет отправляться дважды, окей, на самом деле два разных письма).

Function armyofselenagomez_wpmu_signup_user_notification($user, $user_email, $key, $meta = array()) { // ... // Код из функции wpmu_signup_user_notification() wp_mail($user_email, wp_specialchars_decode($subject), $message, $message_headers); return false; } add_filter("wpmu_signup_user_notification", "armyofselenagomez_wpmu_signup_user_notification", 10, 4);

В результате страница регистрации в теме Селена стала выглядеть намного чище и аккуратней.

Заключение

В интернете множество других не очень правильных способов того, как сделать тоже самое - редиректы Apache, AJAX-формы, которые не будут работать без Java Script и т. п. Все это мне не очень понравилось, поэтому я постарался сделать это максимально правильно на своем собственном сайте.

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

Не забывайте смотреть в исходный код всех описанных выше функций, чтобы полностью разобраться с тем, что и как происходит внутри кода.

Бонус. Защита от спамеров

Даже самые маленькие сайты на WordPress часто подвергаются налету спам-регистраций. Можно писать бесконечные условия для фильтрации ботов, зачастую больше похожие на попытку создать искусственный интеллект 🙂 В случае мультисайта мне очень помог обычный редирект в Apache, с помощью которого при открытии /wp-signup.php и /wp-acitvate.php я попросил выдавать 404 (я не эксперт по настройке Apache, поэтому мои правила могут быть не очень правильными).

RewriteEngine On RewriteBase / RewriteRule ^wp-signup\.php - RewriteRule ^wp-activate\.php - # BEGIN WordPress # Правила от WordPress по умолчанию не трогаем:) # ... # END WordPress

P. S. Я стараюсь максимально детально описывать некоторые сторонние вещи, потому что когда начинал я, порой некому было подсказать и объяснить многие вещи. Также я считаю, что подобные небольшие наводки на другие материалы кого-нибудь подтолкнут к изучению чего-то нового и расширению своей области знаний. В записях RewriteRule используются регулярные выражения, они совсем не сложные, например, символ ^ означает начало строки.