Данная статья не представляет собой всеобъемлющего руководства по программированию безопасных сайтов, она описывает основные принципы безопасности, о которых следует знать при программировании сайтов, и предполагает наличие у читателя базовых навыков веб-программирования и поиска информации в сети. Статья посвящена обзору основных путей взлома веб-сайтов с рекомендациями по защите от них. Упор делается на применение платформы PHP+MySQL, но основные принципы должны быть применимы и для других платформ.

Одним из ключевых принципов безопасности сайта является то, что любым данным, пришедшим извне, доверять нельзя. Даже если данные предварительно проходят проверку с помощью JavaScript в браузере пользователя (и не присылаются в случае его отключения). Даже если это название (User-Agent) браузера пользователя. Даже если это cookie, выставленные нашим же сайтом ранее. Все, что приходит извне, можно подделать. К примеру, один из распространенных форумных движков некогда взламывался из-за того, что злоумышленник посылал запрос с подделанным cookie, вызывая этим SQL-инъекцию (см. далее).

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

Загрузка файлов

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

При загрузке файла PHP в переменной $_FILES[‘userfile‘][‘type’] возвращает mime-тип файла, для JPEG-изображения это будет image/jpeg. Может показаться, что проверка этого типа достаточна для уверенности в том, что загружено именно изображение. Также встречается идея пытаться читать файл изображения функциями getimagesize или imаgecreatefromjpeg. Однако тип файла здесь определяется на основе содержания, так что правильное JPEG-изображение, сохраненное с расширением .php, будет определено как image/jpeg. А называться будет xxxxx.php. Веб-сервер же, принимающий решение об обработчике (handler) для того или иного файла, смотрит именно на расширение. Злоумышленник берет корректную картинку, приписывает к ней в конец (или в EXIF-данные) php-скрипт, и сервер его исполняет, мы взломаны.

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

Также можно хранить файлы в директории, недоступной для непосредственного доступа посетителей веб-сервера, а отдавать их контент через скрипт. Это, однако же, увеличивает нагрузку на сервер и требует реализации базовой функциональности веб-сервера (выдачи даты последнего изменения и реакции на условные запросы типа «If-Modified-Since», выдачи корректных mime-type и поддержки докачки).

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

Register Globals

В PHP есть функциональность «Register Globals» — автоматическое заведение переменных при поступлении их в запросе (GET, POST, COOKIE). То есть, к примеру, скрипт <?php echo $a;?>, будучи вызван как script.php?a=hello, напечатает «hello» при включенных register_globals. Если программист не следит за начальной инициализацией переменных, может возникнуть уязвимость, иллюстрируемая простым примером:

if ($login == 'admin' && $password == 'пароль админа') $is_admin = true;
......
if ($is_admin) {
  какие-то действия, разрешенные только админу
}

Неопытному глазу может показаться, что без знания пароля админа мы не установим переменную $is_admin в true, она останется неопределенной, и if($is_admin) не выполнится. Но переменная $is_admin может быть установлена и путем вызова нашего скрипта с аргументом ?is_admin=1. И из-за того, что мы пропустили переменную из запроса (например, не написали в начале скрипта $is_admin = false), нас и похакали.

Контролировать такие ситуации легче, если включить в PHP отображение всех ошибок, предупреждений (warnings) и замечаний (notices) директивой error_reporting. Мы бы увидели замечание о том, что используется неинициализированная переменная $is_admin. Это одна из причин к тому, чтобы писать скрипты, включив диагностические сообщения PHP на максимум.

SQL-инъекции

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

Пусть у нас есть доска объявлений, на ней регистрируются пользователи, мы разрешаем пользователям через интерфейс удалять свои записи. Вот код PHP-скрипта:

mysql_query('DELETE FROM messages WHERE id='.$message_id.' AND user_id='.$user_id);

Пояснения: переменная message_id приходит от ссылки «Удалить» ($_REQUEST[‘message_id’]), в ней содержится идентификатор удаляемой записи (целое число); переменная user_id хранится в сессии, мы записываем в нее идентификатор пользователя при его успешной авторизации на сайте.

Теперь предположим, что хакер подделал адрес ссылки для удаления и вместо «?message_id=15» отправил нам «?message_id=15 OR 1=1». После подстановки этого значения в запрос он станет таким:

DELETE FROM messages WHERE id=15 OR 1=1 AND user_id=3

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

Другой пример: проверка логина и пароля пользователя, которые поступают в переменных $login и $password:

mysql_query('SELECT id FROM users WHERE login="'.$login.'" AND password="'.$password.'"');

Если в $login хакер отправляет «admin» OR 1=»1», то его пустят на сайт под логином admin даже без знания пароля:

SELECT id FROM users WHERE login="admin" OR 1="1" AND password=""

А если напишет «» OR 1=1 OR 1=»1», то его вообще пустят под первым попавшимся в базе данных пользователем.

Таким образом, основным правилом противодействия SQL-инъекциям является недопущение ситуации, когда данные интерпретируются как выражения. Нужно либо насильно приводить значения в ожидаемый тип (функции intval, floatval, если ожидается число), либо просто заключать их всех в кавычки и экранировать содержащиеся внутри них спецсимволы.

В языке PHP есть специальная функция, экранирующая текст перед вставкой в MySQL-запрос, она называется mysql_real_escape_string. Используемые иногда вместо нее mysql_escape_string, addslashes и (да, да, встречаются и такие странные люди) htmlspecialchars либо неэффективны (см. мануал на www.php.net), либо предназначены для другого (как последняя).

Изначально в язык PHP были введены так называемые «Волшебные кавычки» (Magic Quotes). Это функциональность, при которой PHP сам добавляет обратную косую черту перед всеми кавычками (и уже имеющимися обратными косыми чертами) в данных, поступающих скрипту извне. С одной стороны, это некоторым образом защищает скрипт, автор которого не заморачивал себе голову насчет безопасности своего творения. С другой стороны, данные «портятся» все подряд, даже те, которые и не предначены для запросов к базе. Не хочется же видеть на сайте приветствие «Здравствуйте, д\’Артаньян»? И приходится либо чистить данные функцией stripslashes, либо вообще отключать magic_quotes в настройках сервера.

Да и защита через magic_quotes не стопроцентна: она не предотвратит первую из приведенных выше инъекций, с конструкцией «WHERE id=’.$message_id» — кавычек вокруг аргумента и так нет, хакеру не нужно вставлять закрывающие кавычки. Также не учитывается кодировка соединения с базой данных.

В конце концов, сами авторы PHP не советуют использовать «Magic Quotes» и прекращают их поддержку начиная с 6-ой версии PHP.

Таким образом, уповать на то, что скрипт работает в условиях действующих magic_quotes, не следует, но следует обрабатывать данные перед вставкой в SQL-запросы функциями mysql_real_escape_string / pg_escape_string и обязательно заключать значения в SQL-запросе в кавычки. При этом крайне желательно подвергать такой обработке все данные, участвующие в SQL-запросах, насколько бы надежным ни казался их источник.

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

XSS

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

Очевидно, что в основном XSS угрожает сайтам, на которых регистрируются и оставляют информацию его пользователи (форумы, блоги, доски объявлений), но опасность может угрожать и администраторским интерфейсам, если в них есть модули, предназначенные для просмотра данных, поступающих от посетителей сайта. Это могут быть сообщения из форм обратной связи, заказа или отзывов. Это может быть и статистическая информация об адресах, откуда к нам приходили посетители (поле HTTP-запроса «Referer»), и какими браузерами они при этом пользовались (поле «User-Agent»).

Основным способом противодействия XSS-атакам является фильтрация пришедших извне и публикуемых на сайте данных. Как правило, достаточно заменять символы «<» и «>» на «&lt;» и «&gt;» соответственно (php-функция htmlspecialchars), при этом введенный посетителем текст теряет HTML-оформление, а содержащиеся в нем скрипты утрачивают вредоносность.

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

XSS и BB-коды

Одним из путей являются так называемые BB-коды (Bulletin Board), альтернативные теги, обычно записываемые в квадратных скобках, которые движок сайта потом при отображении заменяет на HTML-аналоги. Набор этих псевдотегов обычно очень ограничен, иногда они даже не могут иметь атрибутов. Либо набор атрибутов также сильно ограничен. Вообще, можно реализовать различные языки разметки, главное, чтобы они четко контролировались разработчиком.

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

Но и BB-ориентированные системы могут быть подвержены XSS-атакам, если при их проектировании сделано отступление от идеи написания языка разметки с нуля. Приведу пример: пусть мы тегом [b][/b] оформляем жирный текст. И при этом разрешаем пользователям с помощью атрибута color менять его цвет. То есть пусть [b color=»red»]…[/b] заменяется на <b style=»color:red»>…</b>. На первый взгляд все хорошо, однако…

Злоумышленник может в значение атрибута color записать что-то посложнее простого цвета, к примеру, он туда запишет строку «red» onmouseover=»скрипт» или «expression(скрипт)». И, если мы не осуществляем должной фильтрации значения цвета, мы получим скрипт, выполняющийся у посетителей.

Хорошей идеей для такой фильтрации будет не вычищать потенциально опасные вещи (к примеру, слово expression или кавычки), а наоборот, пропускать только такие данные, которые являются корректными. В случае с цветом это последовательность латинских букв и цифр, возможно, с символом «#» в начале (т. е., к примеру, регулярное выражение «^[#]?[a-zA-Z0-9]+$». Есть, конечно, в стандарте HTML и другие форматы записи цветов, желающие могут справиться в интернете). Можно пойти дальше, отсеивать, к примеру, цвета, равные или близкие к цвету фона и т. д. Всем этим мы добъемся того, что наш фильтр будет правильно работать и в случае появления поддержки в браузерах каких-то конструкций, которых, возможно, еще и в проекте нет.

XSS и HTML

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

Единственный оставшийся путь — разрешать HTML, но фильтровать в нем все конструкции, подозрительные с точки зрения XSS-уязвимости.

Такая фильтрация довольно сложна, ее сложность усугубляется тем, что браузеры допускают значительные вольности при написании HTML-разметки, стилей и скриптов, могут прощать отсутствующие или незакрытые кавычки, кодированные различными алгоритмами символы, лишние пробельные символы и пр. В качестве иллюстрации рекомендую ознакомиться с памяткой по различным способам XSS-атак на сайте ha.ckers.org.

Поэтому чистить HTML от вредоносных конструкций следует в несколько этапов, и первый их них — исправление ошибок синтаксиса. Для этого можно воспользоваться, к примеру, валидатором Tidy. Он расставит отсутствующие кавычки, «проэскейпит» содержащиеся в атрибутах спецсимволы вроде угловых скобок, закроет назакрытые теги, перенесет в секцию <head> (которую мы просто отрежем) все, что не имеет права находиться в <body> и т. д.

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

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

Полная же задача определения потенциальной зловредности того или иного текста, как уже упоминалась, довольно громоздка, возможно, я опишу ее отдельной статьей или скриптом. Отдельно упомяну, что XSS-атаку можно провести через вставленный Flash-ролик, для запрета роликам вызывать JavaScript-команды используйте атрибут AllowScriptAccess тега <embed>:

<embed AllowScriptAccess='never' ... type="application/x-shockwave-flash"></embed>

Проследить за тем, чтобы не использовались иные type, тоже полезно.

Встретил упоминание о XSS через PNG с дописанным в конец текстом в MSIE. Будем надеяться, что оно пропатчено.

XSS и UTF-7

Отдельно стоит упомянуть использование для XSS-атаки скриптов, написанных в кодировке UTF-7. Эта кодировка замечательна тем, что угловые скобки в ней записываются как «+ADw-» и «+AD4-» и, стало быть, пропускаются функцией htmlspecialchars нетронутыми. Если браузер пользователя настроен на автоопределение кодировки, а ни в заголовках, ни на странице в теге <meta> до любого контента не прописано кодировки, браузер, встретив в контенте характерные для UTF-7-кодировки символы, переключится в эту кодировку и выполнит код.

Например, у нас на форуме название темы идет в тег <title>, секция <head> документов начинается таким образом:

<title>MegaForum - название темы</title>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1251" />

Кодировка прописана, но, к сожалению, уже после вывода поступившего от посетителя названия в <title>. И если он, к примеру, назовет тему

+ADw-/title+AD4APA-script+AD4-скрипт+ADsAPA-/script+AD4-

то в результате браузер прочитает и проинтерпретирует код

<title>MegaForum - </title><script>скрипт</script>

Последствия, думаю, очевидны. А вся проблема из-за того, что <meta> с указанием кодировки не стояла перед <title>. И не было указания кодировки в HTTP-залоговке Content-Type.

CSRF: совершение действия от имени пользователя

Атакой CSRF (Cross-Site Request Forgery) называется отправка запроса через браузер пользователя с одного сайта на другой, так что атакуемый сайт исполняет этот запрос, как будто он поступил от пользователя.

Лучше попробовать понять принцип этой атаки на примере:

Есть сайт A, пусть это форум, на нем зарегистрированные пользователи могут оставлять сообщения. Для отправки сообщения используется обычная HTML-форма с <textarea> и кнопкой «Отправить».

Есть сайт B, в котором сделана копия этой HTML-формы для отправки сообщения, а в атрибуте action у формы прописан адрес сайта А.

Теперь, если некто, залогинившись на форуме А и получив сессионную cookie, зайдет на сайт B, заполнит форму там и нажмет «Отправить», его сообщение пойдет на форум А, словно оно было отправлено не снаружи, а с самого форума. Пользователь-то уже залогинен.

Остается только заманить пользователя с форума на сайт B и отправить эту форму автоматически – с помощью JavaScript-метода submit(), к примеру.

Первый напрашиващийся способ – проверять поле Referer. Ведь в случае прихода пользователя снаружи, в этом поле будет адрес не форума А, а сайта В.

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

Есть, однако, и другой способ. Дело в том, что на сайте В смогли сделать копию формы с форума А только потому, что она, эта форма, у всех пользователей была одинакова. Стоит добавить в нее невидимое (type=»hidden») поле с каким-то уникальным для каждого посетителя параметром, и проверять его при получении этой формы, как мы сможем сказать, что эта форма отправлена с нашего форума А, а не со стороннего ресурса.

Еще один способ: спрашивать ввод CAPTCHA при совершении критических действий вроде смены пароля или перевода денег (как сделано в WebMoney).

Отправка email с сайта

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

Функция mail позволяет отправлять письмо, указывая ему дополнительные заголовки, в которых можно прописать, в частности, адрес отправителя. В самом деле, почему бы не спросить у отправителя его почтовый адрес, чтобы ему в случае чего сразу отправить ответ через «Reply».

Итак, ловим данные и передаем их в функцию mail (обратный адрес из формы в переменной $sender_email):

mail ($admin_email, 'Письмо с сайта', $message, "From: ".$sender_email);

В чем тут проблема: дело в том, что последний аргумент функции mail представляет собой разделенные символами перевода строки заголовки. Нам кажется, что заголовок один — «From». Но представим, что хакер написал в качестве обратного адреса такой набор символов:

hacker@site.com
Cc: email@domain.com

Пусть вас не смущает, что данные введены в 2 строки, а в форме отправки для email было однострочное поле, не дающее писать текст в несколько строк. Как уже упоминалось во введении, все данные, поступающие снаружи, можно подделать. Так что данное письмо будет отправлено не только нам, но и на те email-адреса, который хакер укажет в «Cc:» или «Bcc:» (а он их там может указать сотню). И вот получите ситуацию — через нас рассылают спам.

Решение очевидно — запрещать отправку писем, если во введенном email-адресе используются символы перевода строки (\n и \r).

Отключение кук (cookie)

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

При отключении cookie у посетителя сайт (если он не хочет ограничивать такого посетителя) вынужден дописывать идентификатор сессии к ссылкам и формам на страницах. И адреса страниц приобретают вид навроде «…/forum.php?thread=5&SESSION_ID=abc123…«. На первый взгляд ничего страшного в этом нет, но это только на первый взгляд…

Во-первых, при клике на внешнюю ссылку тот сайт, на который произошел переход с нашего, получает в запросе поле «Referer» — адрес страницы, с которого произошел переход. А в этом адресе — идентификатор нашей сессии. И заходящий по этой ссылке на наш сайт попадает в чужую сессию со всеми вытекающими.

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

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

Основная проблема в том, что секретная информация (идентификатор сессии) доверена несекретному хранилищу (адрес страницы). Cookie, же, напротив, устроены таким образом, что сайт может читать только cookie, выставленные им же самим, и не имеет права читать чужие, это базовая функциональность системы безопасности браузеров.

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

DOS

Несколько особняком в ряду угроз безопасности стоят атаки DOS — Denial Of Service (отказ в обслуживании). Как правило, к этому классу атак принадлежат события, описываемые в новостях «Хакеры атаковали сайт X, нарушив его работу. Сайт не работал в течение Y часов». То есть это именно «атака», а не «взлом». На сервер производятся запросы, которые он не может (не успевает) обработать, в результате чего он не успевает обработать и запросы обычных посетителей и выглядит для них как неработающий.

При желании (и бюджете) можно «завалить» любой сервер. Ограничили количество обращений с одного IP-адреса? Получите DDOS (distributed — распределенный), когда обращения производятся не с одного компьютера, а с тысяч.

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

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

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

Лучше сделать ограничение на количество попыток логина с одного IP-адреса в некоторое количество времени. К примеру — не более 5 в 10 минут. При исчерпании показывать сообщение «подождите» или предлагать ввести CAPTCHA. Некоторые системы просят ввести CAPTCHA вообще при каждой попытке логина.

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

Но как я уже упоминал, против DOS атаки нельзя защититься на 100%, от самого лучшего танка ничего не останется, если в него попасть баллистической ракетой. Но сколько стоит ракета – и сколько танк.

Кража FTP-паролей

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

Переполнение буфера, дыры в серверном ПО

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

«Сам себе злобный Буратино»

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

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

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

Это может быть система фильтрации HTML, где убираются только известные программисту теги <script>, а остальное остаётся…

Это может быть «гениальная» система замены Register Globals, когда программист через $$var=$_REQUEST[$var] или даже eval(‘$’.$var.’=$_REQUEST[«‘.$var.'»]’) заводит переменные, пришедшие из запроса, не соображая, что через эту «форточку» можно как минимум попортить имеющиеся переменные (к примеру, «грохнуть» массив $_SERVER). Через eval же можно вообще выполнить произвольный код.

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

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

  • Вообще, следует отметить, что система безопасности сайта должна быть основана на недоверии ко всей поступающей информации и входящих файлов.
  • Именно этим и пользуются злоумышленники, пытаясь получить доступ к сайту.
  • В зависимости от видов защиты сайтов, принято разделять виды их взлома следующим образом:
  • Вирусная программа. На сегодняшний день, пожалуй, к каждой системе безопасности написан свой вирус, который может эту систему обойти. Вирус доставляется на сервер сайта с помощью различного рода вредоносного программного обеспечения. В мгновение ока, вы можете лишиться важной информации от потери паролей и логинов, и вплоть до потери доступа к любому из ваших сайтов.
  • SQL и PHP инъекции. Весьма опасные инструменты в арсенале талантливого хакера. С помощью SQL-инъекции можно получить доступ к логину и паролю административной панели сайта, что дает большие возможности злоумышленнику. Как правило, SQL-инъекция уместна для сайта, на котором не используется правильное разделение SQL-запросов с вставляемыми в них данными.
  • PHP-инъекция способна на большее. С помощью этого инструмента хакер получает возможность ввести вредоносный код для взлома сайта.
  • Возвращаясь ко всем входящим файлам на сайт, вспомним о загрузке изображений. Очень хороший способ, который позволит взломать сайт. Тематика многих сайтов позволяет любому пользователю загрузить на сайт изображение (к примеру, в формате .jpeg). Этой лазейкой и пользуются хакеры, подменяя и маскируя загрузку изображений в виде исполняемых файлов. К картинке приписывается php-скрипт, что в последствие приводит к получению доступа к ресурсам сайта.
  • XSS атака. Данный вид взлома используют начинающие хакеры, для того чтобы подпортить жизнь неугодному им человеку-пользователю какого-либо ресурса.
  • Cross Site Scripting (XSS) публикует на сайте скрипт, который приходит в исполнение при открытии какой-либо конкретной страницы пользователем. Скрипт получает доступ к фалам cookies и может производить действия на сайте от имени пользователя, что и дискредитирует последнего, при условии что тот «залогинен». Denial of Service («отказ от обслуживания»). Аббревиатура DOS-взлом обозначает скорее атаку на сайт, нежели непосредственный доступ к его содержимому. Подобные атаки часто становятся героями новостей.
  • Новостные ленты звучат обычно так: «На протяжении 3 часов, сайт A не мог обрабатывать запросы пользователей» или «Сайт производителя B не работал на протяжении суток».
  • Смысл DOS-атаки — нагрузить сайт большим количеством задач таким образом, чтобы он был постоянно занят и не мог обрабатывать запросы своих обычных посетителей. Данный способ имеет весьма высокую популярность среди взломщиков.

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

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

1. Обеспечиваем безопасное окружение сайтам: «отсутствие соседей»

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

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

2. Готовим доступы к хостингу и сайту

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

Большая часть работы выполняется нашими специалистами по SSH (в режиме командной строки), поэтому FTP доступов обычно не достаточно. Но если ваш хостинг не предоставляет доступ по SSH, вам необходимо предоставить доступы в панель управления хостингом.

FTP-доступ — это хост, имя пользователя и пароль. Позволяет работать с файлами сайта через специальную программу — файловый менеджер.
SSH-доступ — это хост, порт, имя пользователя и пароль. Позволяет выполнять команды, производить настройку параметров аккаунта хостинга и работать с файлами сайта.
Техническая панель — панель хостинга, где можно создать или посмотреть доступы от FTP/SSH.
Биллинг панель — панель хостинга, где есть доступ к системе тикетов и происходит управление балансом хостинга.
Админ-панель сайта — это адрес страницы, логин и пароль от CMS. Панель, где вы обновляете содержимое сайта (тексты, фото, документы).

Восстановление паролей к хешам, или хешкрекинг (от англ. hash cracking), — весьма увлекательный процесс, для которого требуются хорошие знания в различных областях — криптографии, комбинаторике, программировании и многом другом. Нужно также отлично разбираться в железе, чтобы обеспечить бесперебойную работу своей фермы в течение многих недель и месяцев при максимaльной загрузке.

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

Большинство хешкрекеров на форумах — этакие робин гуды. Они тратят свое время и ресурсы на то, чтобы помочь сломать хеши другим пользователям, и при этом непрерывно накапливают себе новые пароли и правила их формирования. Для них любые хеши — этo вызов их интеллекту, их опыту, их мастерству. И эти парни находят сложнейшие пароли, которые никто другой восстановить не может. Как у них это получается? Каким софтом и железом они пользуются? Что еще нужно знать, чтобы ломать хеши так же эффективно, как они?

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

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

Многие новички спрашивают, как можно поднять, увеличить, повысить Тиц, PR (pagerank) и популярность сайта, блога бесплатно, какие для этого есть способы и методы. Ведь кто-то хочет поднять ТиЦ сайта до 10 или PR (pagerank). Кому-то важна узнаваемость и популярность сайта, чтобы увеличить доверие поисковых машин и стало больше посетителей на сайте.

 

В статье вы узнаете лучшие методы, как увеличить, повысить и поднять Тиц, PR (pagerank), а также что такое популярность сайта, блога и как ее поднять бесплатно в глазах поисковых машин и посетителей. Ведь самые главные показатели сайта это: возраст домена сайта, ТиЦ, PR, посещаемость, поведенческие факторы и ссылки на сайт. Все складывается с внешней и внутренней оптимизации.

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

1. Проверка html: validator.w3 – вставлете в него код своей станицы или просто ссылку на ту страницу сайта, которую нужно проверить на ошибки.

2. Проверка css: jigsaw.w3 – проверяет стили документа.

3. Проверка орфографии: tech.yandex спеллер – проверяет ошибки в тексте.

4. Проверка структуры веб страниц: gsnedders.html5 – показывает структуру веб страницы.

5. Проверка контента и уникальности: content-watch или antiplagiat – проверка текста на уникальность и похожесть на чужих сайтах.

6. Проверка cms сайта: 2ip.

7. Другие полезные сервисы для проверки ошибок и анализа сайта и его страниц: siteliner, urivalet, rexswain, websiteoptimization, seositecheckup, whoishostingthis, whatismyipaddress, webmaster.yandex, tool.motoricerca, siteuptime, iwebtool, semrush, pr-cy, xtool, feinternational, prchecker, SavedHistory, prelovac, seoquake, checker.freeproxy, ahrefs, plusonechecker, vms.drweb, virustotal.

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

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