Прячь скрипты: защита веб-сайта

🕛 12.09.2006, 11:37

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

В данной статье я дам практические советы по обеспечению безопасности динамического веб-проекта, поделюсь нестандартными методами защиты. Много практики и минимум теории - её ищите в мануалах и книгах, а также на просторах Сети. Кроме того, я не буду заострять внимание на всем известных багах навроде “ядерного нуля” - читайте “Хакер”, и будет вам счастье.

Для начала

Для начала определимся с конфигурацией. Мои примеры будут работать на зыке Perl (я буду пояснять их, поэтому портирование на другие языки не вызовет затруднений) и сервере Apache. На практически всех уважаемых хостингах данные вещи присутствуют в необходимом объёме.

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

Самоделкиным

Предположим, что мы забили на скрипты, написанные посторонними товарищами, и решили писать движок “с нуля”. Похвально. Работа закончена, критические ошибки исправлены, мастдайные баги пофиксены. Что теперь? А теперь можно заняться отсечением хакеров уровнем повыше ставших притчей во языцех скрипткидди. Итак, вот несколько эффективных приёмов.

Скрытие языка программирования

Зачем хакеру знать, что наш сайт написан на PHP или Perl? Абсолютно незачем. Смело переименовываем скрипты и даём им расширение .asp, а затем соответственно настраиваем сервер на обработку .asp файлов как Pl/php. Позволит отсечь часть нетерпеливых скрипткиддисов уже на первом посещении.

Скрытие структуры сайта

Будем считать, что сердцем нашего сайта является файл index.pl, лежащий в корне. Ему передаются два параметра: cat (раздел) и id (идентификатор документа). Например, вот URL одной страницы: http://megasite.ru/index.pl?cat=news&id=777. Прибегнем к помощи Mod Rewrite, модуля апача, который установлен на многих хостингах, даже на очень дешёвеньких. Открываем/создаём файл .htaccess, и в нем прописываем следующие строчки:

RewriteEngine On
RewriteRule ^ ([a-zA-Z]+)/ ([0-9]+).html index.pl?cat=$1;id=$2
RewriteRule ^ ([a-zA-Z]+) index.pl?cat=$1

Тадам, теперь эта страница отзовётся по адресу http://megasite.ru/news/777.html, а индекс новостей будет отзываться по запросу http://megasite.ru/news. Пусть наивный атакующий считает, что сайт состоит из хтмл-страниц и ищет админку. Можно, ради веселья, замаскировать свой движок под какую-нибудь известную CMS. Пусть скрипткидди попотеют :) Ещё одним плюсом такого похода является отсечение кривых идентификаторов типа “ ’1 ” и “../../” уже на уровне запроса, до старта выполнения.

NB: не стоит забывать о фильтрации такой бяки и внутри скрипта. Может статься, что его настоящий адрес станет известен, и тут уже Mod Rewrite не спасёт, если не оградить скрипт от прямых запросов через тот же модуль.

Разберём структуру внесённых в .htaccess строчек. В первой задаётся включение механизма переписывания URL. Во второй и третьей с помощью регулярных выражений разбирается строка запроса и переписывается адрес. Я думаю, тут не возникнет проблем. Если регэкспы для тебя тёмный лес, советую прочитать замечательную книгу “Mastering Regular Expressions” от издательства O’Reilly. Она лежит в Сети в виде chm-файла и переведена на русский. Простор для деятельности тут огромный и ограничивается только нашей фантазией.

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

Скрытие ошибок

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

open (FILE, $file) || die (“Не открыть файл $file”);

Безусловно, сие очень удобно при поиске ошибок и отладке. Но зачем, скажите мне, атакующему знать структуру сервера, и имя файла, который бедный скрипт не в состоянии прочитать? Ага. Мы пойдём другой тропинкой. Все die мы заменим на fat_err(“текст_ошибки $!”), а в теле этой функции напишем следующее:

sub fat_error{
$localtime = localtime(); #создаём код ошибки
#начинаем определение айпишника
$user_ip = $ENV{'REMOTE_ADDR'}; 
if ($user_ip eq "127.0.0.1")
{
if ($ENV{'HTTP_CLIENT_IP'} && $ENV{'HTTP_CLIENT_IP'} ne "127.0.0.1") {$user_ip = $ENV{'HTTP_CLIENT_IP'};}
elsif ($ENV{'X_CLIENT_IP'} && $ENV{'X_CLIENT_IP'} ne "127.0.0.1") {$user_ip = $ENV{'X_CLIENT_IP'};}
elsif ($ENV{'HTTP_X_FORWARDED_FOR'} && $ENV{'HTTP_X_FORWARDED_FOR'} ne "127.0.0.1") {$user_ip = $ENV{'HTTP_X_FORWARDED_FOR'};}
}
open (LOG, “log.txt”); #открываем лог-файл
print LOG “$localtime - $user_ip - $_[0] \n-\n”; #пишем туда код, айпишник и текст ошибки
close (LOG); #закрываем файл
print “Вы вызвали ошибку скрипта! Обратитесь к программисту, указав код $localtime”;
die; #умираем со спокойной душой
}

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

Это, как вы понимаете, простейший пример реализации. Можно ещё подкинуть незадачливому взломщику дезинформацию: например, заменить сообщения о невозможности открытия файла сообщениями MySQL. Пусть пытается найти SQL Injection ;) Тут всё опять же ограничивается только фантазией. Экспериментируйте, направление я вам дал.

Режекция непредвиденных фатальных ошибок

“Но ведь то die! А как быть с непредвиденными ошибками?!” - воскликнет вдумчивый читатель, и будет абсолютно прав. Казалось бы, все ошибки отследить нереально: там деление на нуль, тут неверный метод, там вызывается несуществующая функция, тут заглючил Image::Magick... Все эти, и ещё десять тысяч других ошибок, приведут к аварийному завершению работы. Что делать? На помощь приходит блок eval.

Он знаменателен тем, что любой код, заключённый в него, не вызовет фатальную ошибку скрипта. Даже если там будет синтаксическая ошибка! Поэтому некоторые разработчики, в том числе и я, заключают практически весь код в eval.

Для примера возьмём такой код:

print “start”;
eval {&main;}
print “end”;
sub main {$s=5/0; tyt kucha sintaksicheskih oshibok;}

Он, как ни странно, выполнится! И “end” напечатает. При этом в переменной $@ будет содержаться ошибка, из-за которой остановится выполнение eval.

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

Защита от брутфорса

Брутфорс - автоматический перебор паролей. Крайне желательно ввести в базу данных дополнительное поле, в котором будут считаться все попытки зайти с неверным паролём. Как только число в поле превысит, скажем, отметку “10”, аккаунт просто блокируется до выяснения (такой алгоритм, например, используют для защиты sim-карты твоего мобильного телефона). Казалось бы, это очевидно и легко реализуемо парой строчек кода. Всё верно, однако попробуй посчитать количество движков с подобной фишкой. Результат тебя удивит.

Ещё несколько полезных советов

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

fat_error() if $query =~ /\D/;

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

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

Если ты сомневаешься в собственной квалификации, и всё же решил написать движок самостоятельно, могу посоветовать тебе симулировать взлом. Да-да, я не опечатался. Допускаем в коде банальную Sql-инъекцию, запускаем проксик и дефейсим собственный сайт, с этим справится практически любой начинающий, прочитавший хотя бы пару номеров Хакера. Потом заходим уже под своим нормальным айпи и устраняем дефейс. После пишем провайдеру, что наш мега-проект поимели через такой-то скрипт, и просим объяснить, в чём тут дело. Конкуренция среди хостеров немаленькая, и мне известно немало случаев, когда суппорт бесплатно находил в коде ошибки и указывал на них. Есть шанс, что тебе повезёт, и грамотный специалист, изучив твой код, найдёт помимо специально оставленной бреши другие, которые ты оставил по недосмотру/от некомпетентности.

Ещё один относительно часто встречающийся промах: размещение админки по адресам http://site.ru/admin, http://admin.site.ru, http://site.ru/adm и прочее - плохая, очень плохая идея. Даже если папки защищены паролём. Самолично случайно натыкался на админку по адресу http://site.ru/a на одном крупном (~50.000 посетителей в сутки) ресурсе, принадлежащем огромному холдингу. Защиты от брутфорса не было. Скрипт - самописный. Делайте выводы, господа.

Лентяям

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

Скрываем движок

Совсем видоизменить движок проблематично, однако спастись от скрипткиддисов вполне реально. Не секрет, что многие начинающие и не очень хакеры используют для поиска жертв гугль. Как ищутся уязвимые движки? По копирайту. Если твоя совесть девственно чиста вследствие её полного отсутствия как класса, удаляй копирайты совсем, но учти, что это может быть отслежено движком, это аморально и вообще незаконно. Более мягкий способ - это замена латинских букв в копирайте на их кириллические эквиваленты. В самом деле, кто мешает заменить в фразе “Powered by kSearch” буквы “o”, “e”, “a” на их кириллические братья? Внешне всё будет также, но ни один хакер не выйдет на твой сайт через гугль.

Ещё один ход - замена имён переменных. Тут вообще элементарно: функция “заменить” в текстовом редакторе. И всё. Просто и быстро, может спасти от спайдеров.

Прячем админку

Админская панель - лакомый кусочек для взломщика. В первую очередь советую перенести её с дефолтного на другое место и защитить через .htpasswd. Допустим, взломщик всё-таки поимеет наш пароль или куки и найдёт панель админа. Далеко не всё потеряно, мой друг.

Привязка к IP

В большом количестве CMS, форумов, и прочих скриптов за определение личности админа отвечает какая-нибудь функция навроде “is_admin”. Возьмем, к примеру, движок YaBB, в котором такая функция есть. Предположим, что у нас есть статичный айпишник, или же динамический с ограниченным диапазоном (для примера возьмём диапазон “123.123.123.00-123.123.123.255”), и с других мы в админку не входим.

В самое начало функции вставляем следующий код:

$user_ip = $ENV{'REMOTE_ADDR'}; 
if ($user_ip eq "127.0.0.1")
{
if ($ENV{'HTTP_CLIENT_IP'} && $ENV{'HTTP_CLIENT_IP'} ne "127.0.0.1") {$user_ip = $ENV{'HTTP_CLIENT_IP'};}
elsif ($ENV{'X_CLIENT_IP'} && $ENV{'X_CLIENT_IP'} ne "127.0.0.1") {$user_ip = $ENV{'X_CLIENT_IP'};}
elsif ($ENV{'HTTP_X_FORWARDED_FOR'} && $ENV{'HTTP_X_FORWARDED_FOR'} ne "127.0.0.1") {$user_ip = $ENV{'HTTP_X_FORWARDED_FOR'};}
}
die if $user_ip !~ /^123\.123\.123/;

Теперь хакер не попадёт в админку, даже зная пароль.

Скрытые куки

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

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

Резюме

Подводя итоги, замечу, что выбор между своими и чужими скриптами каждый делает сам. Я остановился где-то посредине. Итак, краткий перечень рекомендаций по организации защиты:
Максимально фильтруй поступающую от пользователя информацию, проверяй каждую используемую переменную, используй в качестве идентификаторов числа, вводи избыточную информацию только для запутывания хакера, при этом не обрабатывай её скриптово.
Скрывай ошибки. Если уверен, что обычному пользователю они не встретятся (хе-хе), суй die без объяснений причин.
- Скрывай используемый язык и структуру сервера.
Путай взломщика. Вводи левые параметры, выводи фейковые ошибки. Дезинформация - наше всё.
При использовании чужих движков маскируй их как можешь, и меняй насколько позволяет компетенция и свободное время.

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