Взломай меня, если сможешь

 

Да пребудет с нами сила!

   

Для чего нужно защищать сайты от взлома и нужно ли вообще это делать?

   

Ответ на этот вопрос может показаться парадоксальным, но только на первый взгляд. Проблема в том, что владельцы сайтов не видят никакой проблемы. С одной стороны у них есть мнимое ощущение безопасности и защищенности (до момента первого «ощутимого» взлома), с другой – нет никаких инструментов для того, чтобы это ощущение подтвердить.

   

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

   

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

   

Что же делать, спросите вы? Можно ли защититься от взлома и как? Об этом мы и поговорим в нашей статье. И начнем наш разговор с самого главного – уязвимостей сайта, используемых для его взлома.

   

Откуда берутся уязвимости

   

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

   

Злой умысел – это так называемые «бэкдоры», которые нередко сторонние разработчики оставляют в сайтах, чтобы обезопасить себя от возможных недобросовестных действий заказчика. Более серьезный случай – внедрение «бэкдоров», преследующее корыстные цели, чтобы в дальнейшем получить несанкционированный доступ к сайту с целью извлечения выгоды.

   

Незнание – другая сторона той же медали. Как известно, незнание не избавляет от ответственности. В нашем случае – незнание не защищает от появления «дыр» в коде. Кто-то просто не задумывается о вопросах безопасности, потому что даже не знает, что такое «взлом сайта», кто-то знает, но считает свой сайт «недостаточно интересным», чтобы его взламывали, и по этой причине не прикладывает сознательных усилий к написанию защищенного кода. В любом из этих случаев результат один и тот же, и результат этот плачевен – достаточно всего одной уязвимости, чтобы сайт был атакован с применением всего спектра возможных атак соответствующего типа.

   

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

   

Как уязвимый код попадает на сайт

   

Основные источники появления уязвимостей – это либо свои собственные ошибки, либо сторонний код, который не был досконально изучен и проверен на предмет его безопасности. Таким кодом, которому разработчик сайта доверяет «просто так», может быть CMS (система управления содержимым сайта), используемая для упрощения и ускорения разработки, дополнительные формы и плагины сторонних разработчиков, бесплатно распространяемые форумы, фотогалереи, чаты. А ведь популярность и распространенность выбранного решения напрямую связана с его уязвимостью. Чем популярнее программа, тем подробнее и быстрее каждая новая выпускаемая версия исследуется на предмет безопасности. В сети Интернет можно найти массу сайтов, публикующих информацию о закрытых «старых» уязвимостях и открытых «новых» дырах наиболее популярных на текущий момент веб-программ. Их исследование поставлено на поток, и совершенно не требуется досконально разбираться в веб-программировании или той или иной конкретной платформе, чтобы узнать, где слабое место нового форума phpBB или CMS WordPress.

   

Фрагменты уязвимого кода могут быть также специально внедрены через вспомогательные средства (например, загружены на сайт через уязвимую форму загрузки файлов или изображений). Не стоит забывать и о «злом умысле». Некоторые разработчики специально оставляют бэкдоры (backdoor – уязвимость, используемая для перехвата контроля над сайтом), чтобы, по их словам, «защитить себя от недобросовестности заказчика». Такой бэкдор позволит не только разработчику, но и любому другому злоумышленнику, получить полный контроль над сайтом, если он будет им обнаружен.

   

Основные типы атак

   

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

   

Именно поэтому далее мы будем говорить о наиболее распространенной на сегодня платформе для разработки сайтов – языке веб-программирования PHP и сервере баз данных MySQL. О популярности этой «связки» говорит число сайтов, разработанных с ее применением. Более 20 миллионов. И это число постоянно продолжает расти. Но есть у такой распространенности и обратная сторона – сайты, разработанные по схеме PHP+MySQL, привлекают наибольшее внимание злоумышленников, а методы их взлома совершенствуются день ото дня.

   

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

     

   
• сам браузер, который выступает в роли клиента и отправляет в Интернет запрос на отображение той или иной страницы;
   
• веб-сервер (например, Apache), который получает запрос, обрабатывает его с помощью интерпретатора языка PHP и посылает браузеру ответ в виде HTML-страницы;
   
• сервер базы данных MySQL, где хранятся данные сайта, и к которому обращается программа на языке PHP при формировании конечной HTML-страницы, «отдаваемой» браузеру.
 

     

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

     

Рис. 1. Схема формирование веб-страницы в браузере

   

Что же могут сделать злоумышленники, и как им удается влиять на процесс формирования страниц сайта? Попробуем разобраться.

   

Наиболее распространенными типами атак являются SQL-инъекция, PHP-инъекция и межсайтовый скриптинг. Каждая из этих атак, как следует из их названия, нацелена на определенный участок сайта и определенные уязвимости. SQL-инъекция пытается взаимодействовать с базой данных, PHP-инъекция – с кодом самого сайта, а межсайтовый скриптинг – со скриптами на языке JavaScript, исполняемыми непосредственно в браузере.

Рис. 2. Схема проведения SQL-инъекции

   

В случае SQL-инъекции в переменную, которая используется в одном из SQL-запросов к базе данных, передается специально сконструированное значение, которое направлено на «подмену» выполняемого SQL-запроса. Делается это, например, с целью получения хэш-кода пароля пользователя (в первую очередь администратора), чтобы затем авторизоваться на сайте с правами администратора, не зная самого пароля. Этим, естественно, возможности SQL-инъекции не ограничиваются. Она может быть также использована, например, для получения не просто любых, но абсолютно всех сведений из базы данных или проведения атаки, направленной на приведение сайта в неработоспособное состояние путем перегрузки SQL-сервера, когда посетители сайта попросту не смогут его открыть (аналог DOS-атаки, от англ. Denial Of Service – отказ в обработке запроса).

   

PHP-инъекция направлена на внедрение в код атакуемого сайта вредоносного фрагмента на языке PHP. Обычно это влечет за собой возможность перехвата полного администрирования сайта, т.к. PHP-код, внедренный в сайт, исполняется с теми же правами, что и «хорошие» файлы. PHP-инъекция использует уязвимость часто применяемой схемы навигации, когда основное тело страницы подгружается в общий скелет с помощью команд include, require и других с ними схожих. А имя подгружаемого файла (или часть имени) передается в виде переменной. Злоумышленник пытается подменить значение переменной в надежде на то, что на сервере не закрыта возможность включения удаленных файлов, находящихся на других серверах. В этом случае будет подключен и выполнен произвольный файл, размещенный на атакующем сервере, обычно «шелл» (от англ. Shell – оболочка) – специальная программа для управления атакованным сайтом.

Рис. 3. Схема проведения PHP-инъекции

   

Последняя из наиболее распространенных атак – межсайтовый скриптинг (Cross Site Scripting, CSS) – направлена на выполнение «от лица» зарегистрированного пользователя JavaScript-скриптов непосредственно на пользовательском компьютере, где осуществляется просмотр уязвимого сайта. Делается это в основном для получения файлов cookies, которые затем используются для "перехвата" сессий работы с другими сайтами – почтовыми порталами, форумами, социальными сетями, интернет-магазинами и электронные банками – и авторизации на них от лица атакованного пользователя без знания его пароля.

   

Для того чтобы XSS-инъекция сработала, необходимо, чтобы где-то в тело HTML-страницы выводилась необработанная переменная, например с помощью команды echo. При размещении в этой переменной JavaScript-скрипта он попадает непосредственно в HTML-код страницы и выполняется. Обычно к такого рода атакам уязвимы формы поиска, т.к. в них нередко используется конструкция вида «По Вашему запросу текст запроса ничего не найдено», где текст запроса – никак не обработанная переменная из формы поиска. Другое уязвимое место – форумы и чаты, что особенно страшно, т.к. атаке подвергаются сразу все пользователи, просматривающие зараженную страницу (участвующие в разговоре).

Рис. 4. Схема проведения XSS-инъекции

   

Таким образом, описанные типы атак затрагивают все этапы формирование страницы и работы с сайтом – обработку данных сервером СУБД, выполнение программного кода интерпретатором языка PHP, и даже исполнение JavaScript-скриптов на локальной клиентской машине. Проще говоря, взламывая сайт, можно добраться до любой его части, а также компьютеров всех тех людей, кто этот сайт посещает.

   

Как же все-таки защититься?

   

Теперь, когда мы выяснили, что творится в невидимом мире сети Интернет, пришло время перейти к вопросу «что делать?».

   

Существует две модели поведения: можно надеяться на то, что кто-то другой решит ваши проблемы с безопасностью, а можно защищать себя самому. Как показывает практика, первая модель нежизнеспособна. Возлагать защиту сайта на компанию, оказывающую хостинговые услуги (а больше, попросту, не на кого), в большинстве случаев бесполезно, т.к. интересы хостинговой компании редко простираются далее собственных серверов. Остается вставать на «тропу войны» самостоятельно. И к этому необходимо основательно подготовиться.

   

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

   

Такая проверка может осуществляться по двум радикально различающимся принципам, которые носят названия «черного» и «белого» списка. «Белый список» определяет действия, которые разрешено совершать пользователям. «Черный список», наоборот, определяет запрещенные для пользователей действия. Они работают по принципам «запрещено все, что не разрешено» и «разрешено все, что не запрещено», соответственно.

Рис. 5. «Белый» и «черный» списки

   

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

   

«Черный список», наоборот, не позволит выполнить ни одного действия, признанного вредоносным. Но этот список может быть, во-первых, недостаточно полным, а во-вторых, может привести к излишне жесткой фильтрации, когда корректное действие запрещается, т.к. распознается как вредоносное.

   

У каждого подхода есть свои сторонники и критики. И так сложилось, что «черный список» обычно критикуют больше. Заслуженно ли?

   

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

   

Вместо заключения

   

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

   

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