Несмотря на то что в интернет-окружении существует огромное количество движков для создания сайтов и разных методов работы с нуля, достаточно часто мы можем наблюдать, когда от веб-дизайнеров или веб-верстальщиков ожидают макетов, тем, шаблонов, плагинов, готовых проектов именно для WordPress. Или же требуется настроить готовый и уже запущенный сайт, решить вопросы безопасности, чистоты кода, работу плагинов и прочее, и прочее. Так или иначе, но даже если создается впечатление, что WP очень простой, удобный, легкий и незатейливый – в результате оказывается, что и с ним приходится попотеть, прежде чем в интернете появится действительно качественный проект.
Но чем в частности отличается данный движок от многих аналогов – безопасность. И у нее не самая лучшая репутация в мире. Да, она улучшается, изменяется, но, тем не менее, из года в год более 50 000 – 70 000 сайтов в мире взламывается. Автоматически, на потоке. И вина, что тот или иной сайт взломали, стали использовать для редиректа, системных ресурсов или проведения иных атак не только в том, что сами создатели CMS допускают «дыры» (а затем выпускают заплатку), но и в самих пользователях, создателях, администраторах.
Нет, они знают о безопасности, они что-то делают для её обеспечения, но бывает, что всего этого недостаточно. Мы посмотрим на моменты, которые могут занять гораздо больше времени, чем простая установка плагина по безопасности или изменение некоторых данных. Впрочем, обладать навыками по работе с кодом WordPress все же придется.
Особенности взлома
Если анализировать большинство причин взлома самого WP, то, как правило, страдают более старые версии движка. Обычно на пять версий и более младшие существующей. Иногда и на одну версию, если для прошлой были выпущены спецзаплатки. Хотя, несомненно, современные версии CMS тоже атакуются, но реже. Если не брать в расчёт движок, то взлом осуществляется через плагины, темы, настройки WP и даже через сервер. Тут уже вина за администратором.
Неважно какой сайт вы создаете: кафетерия, портфолио, визитку компании, небольшой интернет-магазин – взламывать его все равно рано или поздно будут. Потому как ботам все равно, какой это сайт – они ищут для хакеров возможности для отправки спама, атаки других сайтов (ваш трафик перенаправляют на целевой сервер и он от совокупного объема «крашится»), для популярного майнинга криптовалюты (затраты на выделенные сервера велики и баснословны), кражы данных пользователей, «теневого» SEO и… многого чего еще.
Соответственно, несложно представить последствия для администратора, пользователей, владельцев, заказчиков таких взломов, которые превращаются в проблемы с репутацией, глобальные финансовые вопросы, головную боль и прочая, и прочая.
Защиты святой троицы
Три ключевых принципа цифровой информационной безопасности появились еще 1975 году и до сих пор используются в интернет-пространстве. Да, они получили развитие, немного изменялись. Но сама суть их никуда не исчезла. Вот и посмотрим на каждый принцип и то, как его можно использовать для улучшения безопасности WordPress (иногда будем сокращать).
Целостность
Не стоит всему слепо верить. Проверяйте цель действий пользователей и целостность обрабатываемых данных. Ничто не может быть достоверным в онлайне, поэтому дважды проверьте все, что вы делаете для предотвращения возможного злого умысла. WordPress отлично себя показывает в обработке данных. Это гарантирует, что каждое взаимодействие проверяется и что каждый бит данных прошел обработку, но… это касается только ядра CMS. Если вы создаете собственный плагин или тему или даже просто проверяете кусок стороннего кода, придется поработать с кодом самостоятельно.
Пример ниже обладает двумя частями данных update_post_meta. Первая – строка, поэтому она переведена в PHP и очищена от разных символов и тегов с помощью одной из функций очистки (санации) – sanitize_text_field. Во второй части добавили число и убедились в его не отрицательности с помощью absint.
Такой вариант более предпочтителен, чем анализ базы данных. В данном случае будут проверяться все данные, которые записываются в базу и важны для инъекций SQL. SQL Injection attack (или инъекции SQL) – вид атаки, что запускает вредоносный код SQL с помощью самой обычной формы на сайте. Этот код способен манипулировать базой данных, чтобы, например, уничтожить все данные, произвести «утечку» пользовательских данных или создать ложные учетные записи администратора.
Поэтому для предотвращения инъекций SQL при работе со сложными запросами или таблицей стоит обратить внимание на функцию prepare и класс wpdb. В примере ниже $wpdb->prepare осуществляет проверку всех переменных в таблице my_table на предмет уязвимости к инъекциям.
Если говорить об XSS-атаках или запуске межсайтовых скриптов, то здесь необходимо понимать важность экранирования данных. Xss-атаки вводят вредоносный код в интерфейсную часть (frontend) вашего веб-сайта. Дополнительным бонусом экранирования данных является то, что вы можете быть уверены, что ваша разметка все еще действительна после этого. В WP много функций по проведению экранирования, условий их использования.
Запросы администрирования CMS безвредны только при наличии SSL. Здесь важно проводить проверку входа и выявлять, действительно ли пытается войти пользователь, прошедший регистрацию. Такое действо WP проводит с помощью Nonces (временных значений). Особенность их в том, что они напоминают маркеры подмены межсайтовых запросов (CSRF), которые обычно есть в файерволлах. Они – гарант того, что хакеры не смогут повторять и выполнять запросы. В реалии это намного большее, чем просто «одноразовый номер», но WordPress любит обратную совместимость, поэтому название прижилось.
Так или иначе, но Nonces отправляются вместе с каждым уязвимым запросом, который делает пользователь. Они прикреплены к URL-адресам и формам и их всегда нужно проверять перед выполнением запроса. Вы можете добавить nonce в код формы или к URL. Вот пример для формы.
Здесь мы использовали обычную функцию wp_nonce_field(), которая создает два скрытых поля. Одно из них проверяет попытку ввода данных с помощью кода в строке 'post_custom_form'. Другое поле использует реферер, который удостоверяется в том, что запрос был сделан именно из WP.
Кроме того, прежде чем провести выполнение запроса из формы, также нужна проверка значения nonce и его валидности. Для этого используется wp_verify_nonce. В данном случае nonce проверяется с действием, и в случае не совпадения обработка формы заканчивается.
И разумеется, наиболее банальное, но чаще встречающиеся недосмотры администраторов и владельцев, что ведут к атакам, это плагины и темы. Даже если они загружены из официальных источников. Бывает, что работают и работают, а со временем сайт блокируют и оказывается, что в коде есть проблемы. Ни одна часть программного обеспечения не является 100% безопасной, но многие плагины и темы либо не обновлены, либо уже изначально были опасными.
Меньшее количество кода означает и меньшие возможности взлома. Поэтому, прежде чем установить еще один плагин, спросите себя: «Действительно ли он вам нужен. Есть ли другой способ решить эту проблему?». Если вы уверены, что вам нужен плагин или тема, то изучите его тщательно. Посмотрите на рейтинг, дату последнего обновления и требуемую версию PHP. Если вы нашли то, что ищете и все, кажется, работает, ищите любые упоминания о нем в блогах безопасности, таких как Sucuri или WordFence (наиболее распространенные).
Другой вариант заключается в сканировании кода и проверке, что он содержит соответствующие nonces, экранирование и санацию. Обычно это те признаки, по которым можно определить безопасный код. Что занятно, не нужно знать детально PHP или делать полный обзор кода. Простой и быстрый способ проверить правильное использование функций безопасности WordPress – поиск в коде плагина строк: $wpdb->prepare; wp_nonce_url; esc_html; sanitize_text_field; wp_nonce_field; esc_attr. И не обязательно должны быть все эти функции в наличии.
Кроме того, обращайте внимание на такие плагины, которые создаются сообществом или несколькими разработчиками. Composer и NPM создали зависимость от библиотек (общими) и именно через них приводилось большинство атак.
Доступность
Принцип доступности основывается на том, что сайт должен быть всегда онлайн и не иметь перерывов в работе. Соответственно, если происходит беда, то необходимо иметь возможность восстановления данных, то есть не лениться и создавать резервные копии. Кроме того, часть проблем безопасности решаются отключением плагинов и обновлением ядра WP, а затем постепенным обновлением/отключением/удалением плагинов. Да, есть инструменты по массовому обновлению от ведущего разработчика WP Mark Jaquith. Но тогда теряется возможность определить уязвимость.
В то же время существует и сервис Sucuri и прочие его аналоги, коих в интернете множество, позволяющие найти хакерский код во всех файлах, повреждения ядра WP. Нет, они не «лечат», но подсказывают где и что можно найти. Это если в бесплатном режиме.
Конфиденциальность
Даже если код сайта безопасен, то само интернет-пространство – нет. Конфиденциальность заключается в воспитании себя, своего клиента и пользователей сайта. Если, например, у вас есть WP_DEBUG со значением true, то каждый хакер будет знать ваш сетевой путь. Отладка данных не должна присутствовать в рабочем проекте.
Другим ценным источником данных являются комментарии и авторские страницы. Они заполнены именами пользователей и даже адресами электронной почты. Хакер может использовать их в сочетании с простым паролем, чтобы попасть на ваш сайт.
И да, пароли, соли, ключи и прочие «данные» - усложняйте их, делайте замысловатыми и сложными.
Завершение
Да, движок WP постоянно обновляется, безопасность улучшается, но само окружение движка небезопасно. Поэтому пользователи/администраторы либо сталкиваются с проблемами и заражениями, либо постоянно работают над безопасностью. Пишите ли вы сами шаблон сайта, плагин или тему, разворачиваете готовые надстройки – за безопасностью следить необходимо. И даже тогда, когда кажется, что самостоятельно ничего невозможно.
Помните о нужных строчках кода, о настройке и проверке плагинов и тем, о требованиях к авторизации, и с глобальной безопасностью можно справиться. Да, мы не рассматривали частные вопросы по настройке серверных файлов, файлов конфигурации. Цель была иная – в том, чтобы рассмотреть те моменты, которые обсуждаются реже, которые не всегда все используют.
