Готов ли ваш сайт к отражению атак?

23/01/201514/02/2015 admin 0 Комментариев Web

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

За всеми этими мерами по укреплению виртуальных границ стоит реальный бизнес. Как мы знаем, веб-сайты привлекают клиентов и помогают зарабатывать деньги.

Многие оффлайновые компании рассматривают Интернет как ещё один рынок, способный привлечь дополнительную аудиторию, а в перспективе и увеличить прибыль.

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

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

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

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

В этой статье мы рассмотрим ряд приёмов, способных укрепить сайт относительно наиболее вероятных атак. Разумеется, по ходу дела мы узнаем, какие именно техники применяют хакеры при поиске уязвимостей.

Основные методы взлома

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

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

SQL-инъекции

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

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

В зависимости от результата этого сравнения пользователю предоставляется (или не предоставляется) доступ к определённым функциям сайта.

Это означает, что имя пользователя используется в качестве параметра в SQL-запросе. И если в обычном случае произойдёт простой поиск и сравнение, то в случае атаки методом SQL-инъекции хакер попытается передать системе вместо ключа для поиска собственный набор SQL-инструкций.

Например, если данные, вводимые хакером в качестве имени пользователя, содержат символ «’» (одинарной кавычки), SQL-сервер воспримет это как конец введённых данных. Следовательно, символы, введённые после кавычки, он воспримет как код SQL-запроса.

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

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

Как защитить сайт от SQL-инъекции?

проверяйте валидность данных формы перед использованием;
используйте параметризованные SQL-запросы;
устанавливайте минимально возможные разрешения для всех таблиц базы данных;
используйте глобальную фильтрацию IIS;
включайте валидацию запросов в ASP.NET;
если вы работаете с SQL-запросами напрямую, подумайте насчёт использования ORM.

Кросс-сайтовые скрипты (XSS)

Кросс-сайтовое исполнение скриптов, являясь скорее легитимной особенностью браузеров, нежели программным дефектом, тем не менее, позволяет хакерам эксплуатировать самые сложные и опасные уязвимости. В недавнем прошлом сайты MySpace, Microsoft и Google подвергались массовым атакам подобного рода.

XSS обычно имеет дело с крошечными кусочками JavaScript-кода, внедряемыми в атакуемые сайты в виде ссылок. Эти скрипты, будучи активированы кликом по ссылке, могут перехватывать управление сессией, воровать ваши приватные данные или клики.

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

О чём тут думать, это же ссылка с «чистого» сайта, верно? И вот вы пытаетесь поговорить с незнакомкой, а вместо этого в адресной строке браузера появляется что-то вроде:

[%63%61%74%69%6f%6e%3d%274%74%70%3a%2f%2f%77%7…]

Вы думаете, что ничего плохого ещё не произошло, но вы ошибаетесь. На самом деле ваши «печеньки» (cookies) наверняка уже попали в руки к хулигану. Прямо как в младшей школе! Имея доступ к вашей сессии, он может прочесть вашу приватную информацию или отправить спам от вашего имени:

Что я могу сделать, чтобы подобное не произошло с пользователями моего сайта?

не вставлять данные, полученные от пользователей или с других сайтов, в произвольные места вашего сайта;
очищать данные, вводимые пользователем, от опасных HTML-тэгов;
очищать пользовательские данные, используемые как атрибуты тегов, от символов вроде «>» и «<»;
экранировать JavaScript-код, прежде чем публиковать чужие данные.

Обход авторизации

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

Процесс взлома может состоять из нескольких простых шагов:

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

Как определить, уязвим ли мой сайт?

ваш веб-сервер работает с привилегиями администратора;
ваше веб-приложение авторизуется в базе данных от лица администратора или пользователя, имеющего более высокие привилегии доступа, чем требуется для работы;
ваше веб-приложение имеет доступ к базам данных или их таблицам, которые не использует в своей работе;
ваше приложение использует настройки carte blanche, вроде AllPermission в J2EE или FullTrust в ASP.NET;
вы можете ограничить доступ приложения к ресурсам системы, но не делаете этого.

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

Как мне защитить мой сайт?

на этапах разработки, тестирования и ввода в эксплуатацию ваш сайт должен запускаться с наименьшими привилегиями из всех возможных;
максимально ограничьте привилегии всех аккаунтов, используемых веб-процессами. Аккаунты типа root, sa, Administrator, supervisor, sysman не должны использоваться никогда;
аккаунты сотрудников, работающих с сайтом, также должны обладать минимальным набором привилегий, позволяющим им выполнять свою работу;
в общем случае, аккаунты даже самых высокопоставленных пользователей не должны обладать административными привилегиями. Отделите мух от котлет на самом раннем этапе.

И ещё раз: существует множество типов атак. Мы рассмотрели наиболее распространённые из них, но это далеко не все. За более подробной информацией обратитесь по следующим ссылкам:

Базовые меры безопасности и предотвращения взломов

Используйте последние версии программ и плагинов

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

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

Короче говоря, хотите дельный совет? Обновляйтесь.

Используйте сложные пароли

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

Так как же нам составить действительно безопасный пароль?

Соль

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

заменить все «a» на «@»;
заменить все «s» на «$»;
заменить все пробелы на «%»;
заменить все «o» на «0»;
заменить все «i» на «!».

При помощи этого правила вы сможете вместо пароля «whoisjohngalt» использовать более безопасный, но почти так же легко запоминаемый «wh0!$j0hng@lt».

Метод Business Insider

Журнал Business Insider недавно опубликовал статью о том, как придумывать безопасные и исключительно хорошо запоминаемые пароли.

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

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

Используйте инструменты для вебмастеров от Google

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

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

Не показывайте версию WordPress

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

Вы можете запретить вывод номера версии, внедрив в файл functions.php вашей темы следующий код:

function wpbeginner_remove_version() {
return '';
}
add_filter('the_generator', 'wpbeginner_remove_version');

Выключите register_globals

Многие пользователи WordPress остаются уязвимыми, потому что не обращают внимания на этот параметр в файле php.ini. И даже несмотря на то, что wordpress.org рекомендует оставить register_globals включённым, вы должны выключить эту функцию, потому что она – лакомый кусочек для хакеров.

Внимательно проанализируйте ваши файлы .htaccess

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

Существует много способов защиты каталогов с кодом при помощи .htaccess, но простейший способ таков:

Order Allow, Deny
Deny from All

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

Следующий способ – более изощрённый:

RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} tag\= [NC,OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)||e|"|;|\?|\*|=$).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*("|'|&lt;|&gt;|\|{||).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%24&amp;x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare).* [NC]
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$

RewriteRule ^(.*)$ - [F,L]

Мой сайт взломан! Что мне делать?

Что делать, если все рекомендации запоздали, и ваш сайт только что был взломан? Как быть?

Не стоит рыдать и биться головой о стену. Мы подготовили отличную статью как раз для вашего случая. Читайте.

Заключение

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

Перевод статьи «Is My Website Ready for Some Serious Hacks?» был подготовлен дружной командой проекта Сайтостроение от А до Я.

Vavik96

Готов ли ваш сайт к отражению атак?