Безопасность сайтов

 

2.3 Выделенный хостинг

Выделенные серверы резервируются  за одним пользователем. Данная форма  хостинга имеет два подвида: управляемый  и неуправляемый.

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

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

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

 

3 Безопасное проектирование

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

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

Некоторые ошибки при планировании инфраструктуры веб–сайтов допускаются столь часто (как начинающими, так и опытными профессионалами), что имеет смысл остановиться на них подробнее.

 

3.1 Файлы cookie

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

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

Файл cookie — это небольшой  файл, создаваемый браузером и  хранящийся на компьютере пользователя. Его содержимое не регламентируется, но обычно в таких файлах хранится название, дата окончания срока действия и некий объем данных, например: «Count = 100» или «Member = false».

Файл cookie сеанса похож на обычный, но при этом он позволяет  веб–приложениям хранить данные в памяти.

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

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

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

В 2007 году сайт MySpace.com подвергся  атаке с помощью трояна JS/SpaceStalk–A, который крал информацию, хранящуюся в файлах cookie, и передавал ее на удаленный сервер. Такая информация может содержать конфиденциальные сведения — имена пользователей, адреса предпочитаемых сайтов и пароли.

 

3.2 Аутентификация

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

Существует несколько  способов аутентификации пользователей: базовая аутентификация, дайджест–аутентификация и HTTPS.

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

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

Протокол HTTPS позволяет шифровать  все данные, передаваемые между браузером  и сервером, а не только имена  пользователей и пароли. Протокол HTTPS (основанный на системе безопасности SSL) следует использовать в случае, если пользователи должны вводить важные личные данные — адрес, номер кредитной  карты или банковские сведения.

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

 

3.3 Компоненты, библиотеки и надстройки

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

Причины для использования  настраиваемых систем, предлагаемых сторонними разработчиками, очевидны: экономия времени и средств.

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

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

 Wordpress (блог).

phpBB (форум).

CMS Made Simple (CMS).

 PHPNuke (CMS).

bBlog (блог).

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

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

 

3.4 Лог–файлы

Серверные лог–файлы — весьма важный инструмент управления веб–сайтом. Обычно HTTP–серверы способны вести раздельные журналы доступа и ошибок; при наличии подобной функциональности ее следует использовать в обязательном порядке, поскольку это может пригодиться для последующего анализа.

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

 

4 Обеспечение безопасности  кода

Разрабатывать безопасный код  не всегда так просто, как кажется. Для этого нужны не просто опытные  программисты — также требуются  знания о конкретных проблемах безопасности. Разработке безопасного кода посвящены  многие книги, поэтому здесь рассматриваются  только основы.

Глобальные переменные всегда следует отключать, поскольку их можно намеренно инициализировать с помощью подложного запроса GET или POST.

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

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

 

4.1 SQL–инъекция

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

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

Рассмотрим следующий PHP–код:

$firstname = $_POST["firstname"]; mysql_query(«SELECT * FROM users WHERE first_name=’$firstname’»);

После того, как пользователь введет свое имя в веб–форме, SQL–запрос вернет список всех пользователей с тем же именем. Если указать в форме имя «Крис», то SQL–запрос будет иметь следующий вид:

 «SELECT * FROM users WHERE first_name=’Chris’»

Это допустимая конструкция, которая сработает так, как ожидается. Но что случится, если вместо имени  ввести, например, «’; drop table; #»? Тогда  конструкция будет выглядеть  следующим образом:

 «SELECT * FROM users WHERE first_name=»; DROP TABLE users; #’»

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

 SELECT * FROM users WHERE first_name=»;

Исходная инструкция теперь бесполезна — ее можно пропустить. Вторая инструкция приведет к тому, что в базе данных будет целиком  удалена соответствующая таблица, а стоящий в третьей строке символ «#» приведет к тому, что MySQL проигнорирует оставшуюся часть  строки.

Приведенная в примере  уязвимость особенно опасна, поскольку  ее можно использовать для вывода закрытых данных, изменения отдельных  полей или удаления информации. Некоторые  СУБД также позволяют выполнять  системные команды с помощью SQL.

К счастью, этот вид угрозы легко устраним благодаря проверке вводимых пользователем данных. В PHP имеется специальная функция mysql_real_escape_string, удаляющая из строки потенциальный  код SQL–инъекции. Ее следует использовать для фильтрации всех данных, внедряемых в SQL–инструкции.

 

4.2 XSS (межсайтовый скриптинг)

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

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

Подобные атаки обычно реализуются с помощью вредоносных  скриптов на языке Javascript, которые затем  загружают контент с другого  веб–сайта. Предполагается, что в базе данных хранится имя пользователя, но на самом деле в данном случае это будет вредоносный код. Соответственно, если веб–сайт отображает имя пользователя в верхней части страницы, то этот код будет выполнен. Поскольку при наличии определенных условий такой код может делать практически все, что угодно, угроза становится вполне реальной; тем не менее, разработчики зачастую про нее забывают. За последнее время жертвами XSS–атак стали многие популярные веб–сайты, в том числе MySpace, Facebook, Google Mail, ВКонтакте.

Рассмотрим следующий PHP–код:

$firstname = $_POST["firstname"]; echo «Your name: $firstname»;

После ввода имени в  веб–форме сайт отображает на странице соответствующее сообщение. Если указать в форме имя «Chris», то сообщение будет иметь следующий вид: «Your name: Chris».