Яндекс назвал самые уязвимые CMS. Самые безопасные cms

Безопасные и небезопасные CMS | mens semper aliquid anquirit

В настоящее время для управления структурой, контентом и дизайном сайтов часто применяются системы управления содержимым сайта – Content Management System (CMS). К CMS можно отнести:

универсальные системы для управления контентом;
интернет-магазины;
блоги, форумы, wiki;
фото- и видеогалереи, движки виджетов;
другие компоненты для управления содержимым сайта.

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

В то же время, CMS, как и другие виды ПО, содержат уязвимости. В отличие от CMS собственной разработки, если злоумышленники находят уязвимости в одной конкретной тиражируемой CMS – возникает угроза взлома всех CMS этой версии. При этом, чем более распространённой является система и чем чаще она применяется на популярных сайтах, тем больше усилий и денег злоумышленники инвестируют в поиск её уязвимостей.

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

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

Общая статистика по CMS

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

Видно, что 50% из топ-10000 заражённых сайтов используют систему DLE, а популярные сайты из топ-10000 либо отказались от неё, либо успешно её маскируют, чтобы избежать атаки. При этом они продолжают использовать WordPress и Joomla, которые тоже часто встречаются на заражённых сайтах.

WordPress

Из наших данных следует, что частота использования большинства версий CMS WordPress на обычных и на заражённых сайтах примерно одинакова. При этом чаще всего заражёнными являются сайты, использующие WordPress 3.2.1, 3.1.3 и 2.9.2, эти же версии широко распространены на незаражённых популярных сайтах. Вебмастерам таких сайтов стоит соблюдать правила безопасности особенно тщательно, чтобы не допустить взлома и заражения.Только за август и сентябрь 2011 опубликовано 57 новых уязвимостей WordPress, причём все они находятся в дополнительных компонентах. Уязвимости присутствуют в модулях wp-forum , wp-slimstat, wordpress automatic upgrade и других. С общим обзором уязвимостей WordPress можно ознакомиться здесь.

Joomla

Анализ показывает, что CMS Joomla версии 1.5 одинаково часто встречается как на обычных, так и на заражённых сайтах. Владельцам сайтов, использующих эту версию Joomla, тоже рекомендуется уделять безопасности особое внимание. С начала года было опубликовано 38 новых уязвимостей в компонентах Joomla. В частности, об уязвимости в Joomla Datsogallery 1.3.1 можно прочитать на этой странице, а детальный список уязвимостей приводится здесь. Рекомендуем тщательно проверять на наличие уязвимостей модули Joomla, которые используются для реализации форумов.

Обеспечение безопасности сайта при разработке

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

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

1. Выбор надёжных средств проектирования, или надёжной CMS

Небезопасная CMS - это самый востребованный хакерами объект для атаки, потому что используется многими пользователями, значит взлом можно повторять на множестве обнаруженных сайтов. Поэтому перед выбором CMS, удовлетворяющей требованиям безопасности, нужно изучать вопросы безопасности каждой CMS, выяснять соответствие системы критериям безопасности. Об этом могут свидетельствовать:

обсуждения в Интернете случаев взлома,
статистика взломов различных CMS из достоверных источников, например, https://blog.sucuri.net/,

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

Для примера на официальном сайте CMS Drupal существует раздел отчётов о безопасности и обновлениях безопасности https://www.drupal.org/security. Для WordPress также существует множество гидов, например: http://codex.wordpress.org/Hardening_WordPress. Что-то об этом сказано и на сайте Joomla! : https://docs.joomla.org/Security_Checklist/You_have_been_hacked_or_defaced

Какая CMS безопасна?

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

При использовании готовой CMS для управления безопасностью желательно:

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

Отключать неиспользуемые компоненты. Отключать все неиспользуемые функции нужно сразу после установки. Большинство систем предлагают базовые функции: регистрация пользователей, поиск, комментарии, публикации, оценки, вход через соц. сети. Этот интерактив может быть причиной взлома сайта, поэтому любой интерактив и любое взаимодействие сайта с посетителем нужно отключать при неиспользовании. Это может стать не только причиной взлома, но и засорения сайта и его последующим исключением из поиска (на практике такое случалось с livestreet cms).

Разбираться в API-функциях при написании модулей, программ. Существуют стандарты кодирования для CMS (например, принципы кодирования для Drupal), которых нужно придерживаться при написании функций.

Управлять обновлениями CMS. Локальный сайт - самый безопасный. Обновления зачастую могут привести к заражениям, и это может происходить разными путями: перехватом соединений с удалённым сервером, взлом главного сервера, хакерской активностью в пределах хостинга, на котором размещён сайт. Поэтому процесс обновления должен быть отключаемым и при необходимости производиться в ручном режиме.

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

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

Как создавать безопасный сайт?

Проектирование собственной системы или доработка функций готовой CMS должны удовлетворять требованиям:

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

Разграничение уровней доступа пользователей. Роли - это выделяемые пользователям наборы возможностей, разрешений. Каждому пользователю изначально должны предоставляться максимально ограниченные возможности, то есть для роли "неавторизованный посетитель" может выделяться только возможность просмотра материалов, подписки на новости и, возможно, регистрация на сайте, комментарии. Для роли "зарегистрированный пользователь" могут предоставляться права обращения за поддержкой, создание тикетов, публикации на сайте материалов с модерацией, изменение имени, восстановление пароля и т.д. Функция разграничения прав - это базовая функция, реализуемая на многопользовательских проектах. Без неё невозможна разработка многопользовательских Интернет-сайтов.

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

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

Защита от ботов. Ограничение активности ботов призвано предотвратить подбор паролей, тестирование инъекций.

Права на файлы и папки Linux. Для большинства хостингов права на папки выставляются 755, на файлы - 644. Для папки временных файлов и загружаемых пользовательских файлов, возможно предоставление права записи 775 или даже 777. Желательно при этом обеспечить защиту с помощью .htacccess внутри этой папки.

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

Сокрытие структуры CMS, её фалов и папок. Это означает, что при обращении к папке сайта, в которой нет index.html, не должен выводиться список файлов папок, также при отображении ошибок сайта не желательно показывать эти ошибки анонимным пользователям, которые могут увидеть пути сайта и адреса файлов скриптов.

Обработка сообщений об ошибках. Хакерам довольно просто вызвать ошибки на сайте, часто для этого бывает достаточно ввести параметры в url после знака "?". Сообщения об ошибках дают представление о структуре, информацию о работе функций сайта, поэтому нежелательно показывать их все. Некоторые или все сообщения желательно записывать в базу данных или специальные лог-файлы, используя обработчик сообщений об ошибках.

Ограничение потребляемых ресурсов. При обработке ошибок 404 нужно ограничить потребляемые ресурсы: например, создать статичную страницу 404.html. Также при атаках DDOS нужно отлавливать возможные ошибки и ограничивать работу сайта или его функций. Часто при переполнении памяти сервера (при атаках DDOS) функции сайта могут давать сбои, которые могут открыть хакеру важную информацию о конфигурации сервера, системы CMS.

Настройки безопасности сервера. Некоторые ошибки в работе сервера (apache, nginx) или ошибки в .htaccess могут приводить к тому, что все исполняемые файлы не исполняются, а отображаются как текст. В таком случае хакер может прочитать файл настроек и узнать пароли баз данных, возможно, администратора сайта, также ftp.

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

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

Другие рекомендации читайте в рубрике Безопасность или в предложенных темах под статьёй.

www.tlito.ru

Яндекс назвал самые уязвимые CMS

На днях команда Безопасного поиска Яндекса затронула в своем блоге такую насущную тему, как уязвимости CMS и ее безопасность. Как правило, такие системы, как и любое другое ПО, содержат уязвимости, которыми при каждом удобном случае не преминут воспользоваться злоумышленники. Причем, чем популярнее CMS, тем больше вероятности, что слабые места будут искать именно в ней. Не стоит забывать и о том, что современные CMS преимущественно состоят из множества модулей, которые не так хорошо тестируются на безопасность, как основной код системы.

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

Яндекс проанализировал ТОП-10 000 популярных зараженных сайтов. Оказалось, что подавляющее большинство используют систему DLE (50%), также популярны WordPress (19%) и Joomla (19%). Наиболее незащищенными версиями оказались: WordPress 3.2.1, 3.1.3 и 2.9.2 и CMS Joomla версии 1.5. Конкретнее узнать о слабых местах каждой системы можно здесь.

Рекомендации, как предотвратить взлом CMS, достаточно просты:

1. Регулярно обновлять CMS.

2. Не указывать ее тип и версию в коде страницы.

3. Отказаться от контрафактных версий систем.

4. Следить за всеми данными, которые пользователь может ввести на страницах сайта или передать серверным скриптам при помощи запросов.

5. Сократить число используемых сторонних скриптов, модулей и расширений.

6. Не забывать о правилах безопасной работы в Интернете.

7. Перед установкой на веб-сервер ПО проверить его уязвимости и узнать о их устранениях с помощью The Open Source Vulnerability Database.

Рассказать друзьям: