Ядро WordPress не является небезопасным по своей природе. Это один из самых тщательно проверяемых исходных кодов в интернете, который поддерживается отдельной командой безопасности с формальным процессом раскрытия уязвимостей, программой bug bounty и автоматическим фоновым патчингом для релизов безопасности. Серьезные уязвимости ядра встречаются редко, а когда они появляются, их обычно патчат и автоматически разворачивают на миллионах сайтов за считанные часы. Если бы проблема была в самом ПО, веб сгорел бы еще много лет назад: WordPress обеспечивает работу примерно 43% всех веб-сайтов и удерживает более 60% рынка CMS.
Из-за чего на самом деле взламывают сайты на WordPress
Причина взлома сайтов на WordPress почти никогда не кроется в самом WordPress. Это два фактора, которые накладываются поверх него:
- Плохие хостинг-окружения. Шаред-серверы с устаревшим PHP, отсутствие изоляции между аккаунтами, доступные для записи файловые системы там, где этого быть не должно, отсутствие WAF, отсутствие сканирования на вредоносный код, все еще включенный FTP и бэкапы, которых на поверку не оказывается. Защищенный хостинг с изоляцией PHP, разумными правами доступа к файлам и файрволом на уровне edge устраняет целые категории атак еще до того, как дело доходит до WordPress.
- Плохо написанный код плагинов и тем. Именно здесь кроется подавляющее большинство реальных уязвимостей WordPress. Каждая сводка статистики от вендоров безопасности из года в год говорит одно и то же: на плагины приходится более 90% раскрытых уязвимостей WordPress, в то время как само ядро — это погрешность округления. Непроверенный плагин выполняется с полными привилегиями приложения; его установка — это решение о доверии, а не решение о функционале.
Иными словами, у людей есть возможность сделать WordPress небезопасным, и многие с энтузиазмом ей пользуются: полсотни плагинов неизвестного качества, тема, купленная на маркетплейсе и ни разу не обновлявшаяся, пароли администратора, используемые повторно после утечек с других сервисов, хостинг, выбранный исключительно по цене. Ничто из этого не является проблемой WordPress. Те же самые решения скомпрометировали бы любую платформу.
Почему взломам WordPress уделяют так много внимания
WordPress — самая популярная CMS в мире, и один этот факт объясняет большую часть ее репутации. Когда что-то обеспечивает работу 43% веба, естественным образом следуют три вещи:
- Это самая большая мишень. Злоумышленники используют автоматизацию, а автоматизация направлена туда, где больше всего установок. Эксплойт для WordPress имеет десятки миллионов потенциальных целей; эксплойт для нишевой CMS — тысячи. Объем атак на WordPress — это функция от его популярности, а не от его качества.
- О каждом инциденте сообщают как о «взломе WordPress». Когда сайт с заброшенным плагином слайдера на хостинге за $3 подвергается дефейсу, в заголовке пишут «WordPress». Аналогичный взлом самописного сайта вообще не попадает в заголовки, потому что в него нечего вставить в качестве бренда.
- Знаменатель остается невидимым. Вы слышите о взломанных сайтах и никогда — о сотнях миллионов тех, которые спокойно работают без проблем. Судить о безопасности WordPress по заголовкам о взломах — это все равно что судить о безопасности автомобилей, читая только отчеты об авариях самой продаваемой модели.
Мой собственный опыт
За все годы, на каждом сайте, который я создал и администрировал — от проектов соло-фаундеров до корпоративных изданий с миллионами посетителей и реальной выручкой — ни один не был взломан или скомпрометирован. Это не везение и не комплексные средства защиты. Все сводится к нескольким осознанным привычкам:
- Минималистичные системы. Чем меньше кода вы запускаете, тем меньше возможностей для эксплойтов. Я разрабатываю кастомные темы ровно под нужды сайта, держу список плагинов коротким и скучным и удаляю все, что не оправдывает свое присутствие. Большинство моих продакшен-сайтов используют лишь малую часть того количества плагинов, которое стоит на типичном инсталле.
- Разумный хостинг. Управляемый (managed) WordPress-хостинг с надлежащей изоляцией, актуальным PHP и защитой на уровне платформы вместо дешевого шаред-хостинга, где вы наследуете проблемы своих соседей по серверу.
- Умный мониторинг и защита на уровне DNS с помощью Cloudflare. WAF, защита от ботов и rate limiting на уровне edge означают, что credential stuffing, сканеры эксплойтов и brute-force атаки блокируются до того, как они вообще дойдут до WordPress. Добавьте к этому реальный мониторинг — и вы увидите формирующиеся паттерны атак вместо того, чтобы обнаруживать их последствия.
- Обновления всегда и без исключений. Ядро и каждый плагин всегда находятся в актуальном состоянии, при этом обновления тестируются на staging и быстро деплоятся. Почти каждый массовый взлом в истории WordPress эксплуатировал уязвимость, для которой уже был доступен патч.
- Никаких плагинов, которые вы боитесь обновлять. Это негласное правило, которое делает большую часть работы. Если обновление плагина вас пугает, такой плагин по определению является риском: это значит, что код хрупок, заброшен или настолько запутан в вашем сайте, что контролирует вас, а не наоборот. Замените его. Плагин, который вы не можете обновлять без страха — это уязвимость с часовым механизмом.
Заметьте, чего нет в этом списке: плагинов безопасности. Я их не использую. Большинство вещей, которые они продают — файрволы, ограничение попыток входа, сканирование — лучше делаются на уровнях DNS и хостинга, за пределами приложения, где злоумышленник не может до них дотянуться. Файрвол, работающий внутри объекта, который он защищает, уже находится в зоне поражения, а громоздкие комплексные средства защиты добавляют собственную поверхность атаки, снижают производительность и создают ложное чувство того, что безопасность «закрыта».
Open Source против закрытых систем
Обычный вывод, к которому приходят люди после испуга — нужно перейти на закрытую проприетарную платформу, где кто-то другой берет все на себя. Вам не нужна закрытая система, чтобы быть в безопасности, к тому же закрытые системы несут собственные риски, о которых редко говорят в коммерческих презентациях:
- Безопасность через неясность (obscurity) — это не безопасность. Открытый исходный код означает больше исследователей, аудирующих код, а не меньше изъянов в нем. Уязвимости в проприетарных платформах существуют; вы просто не можете их увидеть, проверить исправление или самостоятельно провести аудит кода. В случае с WordPress тысячи исследователей открыто изучают все подряд, что бывает некомфортно, но именно благодаря этому проблемы всплывают и исправляются.
- Вы устанавливаете патчи по их графику. В закрытой платформе вы не можете исправить что-либо самостоятельно, нанять кого-то, кто сможет, или хотя бы подтвердить наличие проблемы. Вы ждете в уязвимом положении вендора, чья политика раскрытия информации склоняется к молчанию.
- Один вендор, один взлом — пострадают все. Централизованные закрытые системы концентрируют риск: единичная компрометация вендора затрагивает всех клиентов одновременно, и их инцидент становится вашим инцидентом с нулевым предупреждением и нулевым контролем.
- Привязка к вендору (lock-in) — это самостоятельная угроза. Если вендор поднимает цены, закрывает функции, сталкивается со сбоем в работе или закрывается, ваш единственный вариант — миграция, которую вы больше не контролируете полностью. Невозможность уйти — это проблема безопасности на уровне бизнеса.
Безопасность — это не свойство открытости или закрытости. Это свойство того, как система построена, где размещена, как мониторится и обслуживается. WordPress, запущенный с минимальным количеством кода, на серьезном хостинге, с edge-защитой и дисциплинированными обновлениями, безопасен так же, как и все остальное в вебе, и у меня есть пара десятилетий неповрежденных продакшен-сайтов в подтверждение этого. Платформа никогда не была проблемой; проблема — в подходах к ней, и именно их вы полностью способны контролировать.
Комментарии (0)
Пока нет комментариев — будьте первым.