Автор: Михаил Кепман
С каждым днем количество сайтов в Сети увеличивается на радость пользователям. Но вместе с тем, к сожалению, неуклонно растет и число желающих эти самые сайты взламывать. Для одних это сомнительное удовольствие, сравнимое с написанием матерных слов на заборе, для других — работа.
Но вне зависимости от того, что толкает хакеров на деструктивные действия, их арсенал вполне традиционен. Как раз об этом мы и решили поговорить с экспертами, рассматривая вопросы безопасности в современных массовых CMS.
Одним из самых популярных методов взлома по праву считаются SQL-инъекции. О нем рассказывает Виталий Камлюк, старший вирусный аналитик «Лаборатории Касперского»: «Проблема SQL-инъекций весьма реальна и довольно серьезна. Объясню почему. В любой системе есть код и данные. Эволюция информационных систем разделила два этих понятия, и сегодня мы видим, что данные находятся в отдельных хранилищах, называемых базами данных. Что касается веб-систем, то чаще всего наибольшую ценность представляют собой данные, хранимые в них. SQL-инъекции нацелены как раз на то, чтобы атаковать веб-системы и получить доступ к системе управления базами данных (СУБД). С помощью SQL-инъекций злоумышленник может копировать все данные, хранимые в СУБД, получать неавторизованный доступ к системе, выводить систему из строя, уничтожать данные СУБД и, в некоторых случаях, получать полный контроль над сервером. Лучшей защитой от SQL-инъекций является аккуратная проверка тех частей кода, которые обрабатывают данные поступающего на сервер HTTP запроса и подготавливают их для включения в качестве параметров SQL-запроса, отсылаемого далее СУБД. Впрочем, понимая, что на разработчика не всегда можно положиться, создатели современных интерпретаторов (например, самый популярный в сети — PHP) изобретают встроенные защиты от SQL инъекций. Так, например, если включить в конфигурационном файле PHP режим интерпретатора magic_quotes, использование SQL-инъекции становится более сложной задачей и значительно сужает область уязвимого кода».
«Это действительно одна из самых популярных уязвимостей на данный момент, — соглашается Сергей Антонинко, технический директор umisoft, — Решение этой проблемы предельно простое: перед передачей внешних данных в запрос экранировать недопустимые символы, либо использовать плейсхолдеры (при использовании mysqli, например). Вообще, это обычная болезнь начинающих разработчиков. В зрелых проектах я подобных уязвимостей не замечал».
Денис Миронов, руководитель отдела информационной безопасности компании «1C-Битрикс», также рассказал нам о классических методах защиты от SQL-инъекций: «Начнём со стадии разработки продукта. Первое, что должны сделать разработчики — обезопасить данные пользователя системы, то есть проверять ВСЕ данные, приходящие от пользователя системы, а также данные, передающиеся различными способами с клиентской системы — cookies, скрытые параметры, POST запросы и т.п. Есть типовые варианты борьбы с инъекциями вредоносного кода методом отсечения(экранирования) кавычек из запроса — стандартная функция mysql_escape_string и ей подобные. Но, это не панацея для разработчика системы так как система будет работать в разных условиях, на разных платформах, и использование типовой функции на некоторых из них будет просто невозможно, а соответственно приведет к уязвимости всей системы в целом.
Более грамотный подход, предполагает разработку «оберток», когда параметры запроса «скармливаются» объекту при помощи присваивания значений свойствам или вызовов отдельных методов. Существует немало моментов, которые необходимо предусмотреть при проектировании и разработке «оберточных» функций системы. Вторым этапом является правильная и безопасная интеграция системы на платформу и БД. На этом этапе необходимо отключить функции, которые могут помочь атакующему, правильно сконфигурировать периметр сети, системы IDS и многие другие необходимые мероприятия. На заключительном этапе необходимо сделать независимый аудит безопасности сконфигурированной системы, это позволит выявить и своевременно устранить недочеты безопасности, возникшие в ходе интеграции».
«Кроме SQL-инъекций есть и другие популярные уязвимости веб-сайтов, — продолжает Виталий Камлюк. — Например, PHP-including, PHP-injection, XSS (cross site scripting) и другие. Все они имеют разные уровни опасности и разделены на две группы — уязвимости с кодом, исполняемым на стороне клиента, и уязвимости с кодом, исполняемым на стороне сервера. С точки зрения владельцев сайтов, наибольшую опасность представляют уязвимости находящиеся на стороне сервера, поскольку проникновение злоумышленника на сервер может означать полное уничтожение сайта или критичную потерю конфиденциальных данных».
Дмитрий Васильев, генеральный директор компании «АИСТ», подчеркивает, что не стоит сбрасывать со счетов и человеческий фактор. В частности, речь идет о небрежном обращении с паролями, от которого страдает масса начинающих сайтостроителей.
Несмотря на то, что инструментарий хакеров давно известен, их изобретательность не имеет границ. Они умудряются выдумывать все новые способы взлома, не выходя за рамки вышеописанных слабых мест, и порой разработчики CMS проигрывают в этой гонке, не успевая выпускать очередные заплатки для своих систем. «Существует статистика, которая показывает, что 60% веб-систем, работающих с данными, является уязвимыми для SQL-инъекций. Мы не занимаемся анализом уязвимостей веб-систем и не собираем статистику по числам SQL инъекций, но нам известно, что всякая популярная веб-система так или иначе хотя бы раз попадалась на уязвимости для SQL-инъекций», — подчеркивает Виталий Камлюк. «Думаю, не стоит называть конкретные системы. Где-то год назад мы проводили исследования, и могу сказать, что большинство систем, не входящих в условный «TOP-10», имеют набор легкообнаружимых уязвимостей», — добавляет Сергей Антонинко.
«Ни один из существующих на рынке программных продуктов не может считаться абсолютно защищенным, — подчеркивает Дмитрий Васильев. — Составить рейтинг небезопасных CMS невозможно, да и не имеет смысла, потому как дыра дыре рознь: один продукт может содержать множество возможностей несанкционированного чтения закрытых данных, а другой — одну-единственную дыру, но критическую».
Казалось бы, с точки зрения безопасности выбор CMS вполне очевиден — популярные платные системы наверняка лучше защищены, нежели менее известные или вовсе бесплатные аналоги. По большому счету, так оно и есть, но у популярности существует и обратная сторона – повышенное внимание хакеров. К счастью, у известности, кроме финансовой составляющей, есть и свои плюсы. «Популярная система вместе с тем, что привлекает внимание злоумышленников, является и объектом внимания множества разработчиков, которые могут указать на имеющиеся уязвимости, — считает Виталий Камлюк, — поэтому, как правило, чем популярнее система, тем меньше в ней брешей. Но не стоит думать о том, что если у злоумышленника нет исходных кодов системы, то он не может применить SQL инъекцию. Сделать это сложнее, но абсолютно реально!».
В защиту популярных CMS выступил и Михаил Кондрашин, руководитель Центра компетенций Trend Micro в России и СНГ: «Чем популярнее CMS-система, тем больше злоумышленников ищут в ней уязвимости. Но большое количество обнаруженных уязвимостей популярного продукта не означает его уязвимость в целом. Выбор малоизвестного продукта приведет к определенным рискам, которые могут оказаться гораздо больше рисков взлома. Малоизвестный продукт может не удовлетворить заказчика, и сайт вообще не будет создан, а популярную CMS можно всесторонне протестировать. Можно ознакомиться со сходными проектами, построенными с ее использованием. Главное — это проработать сценарий взлома, так как он может произойти с любой системой. Уточнить, как будет выявляться факт взлома, что, кем и в какие сроки будет делаться для устранения ущерба. Заказчикам нужно узнать, насколько оперативно предоставляются вендором заплаты, насколько сложна процедура их установки. Так как риск взлома нельзя исключить, его нужно учесть. Соответственно, при обнаружении уязвимости необходимо, чтобы установка заплаты не приводила к остановке сайта, а в случае взлома весь сайт можно было бы восстановить из актуальной резервной копии за минимальное время».
Благодаря хакерам или, если точнее, — вопреки им, на рынке CMS, наконец, появляется некоторая определенность. Если ранее мы рассматривали возможности opensource-систем, которые по функционалу не уступают коммерческим CMS, то теперь в этом вопросе, наконец, можно поставить точку. Исходя из соображений безопасности, можно предположить, что альтернатив популярным платным системам управления контентом просто не существует. Даже если проект, на первый взгляд, неинтересен хакерам, то от попыток взлома вандалами никто не застрахован. С прискорбием вынуждены сделать вывод, что opensource и безопасность в данном случае вещи практически несовместимые.