n  нам необходимы куки жертвы;

n  идентификатор сессии, который мы можем найти в переменной $ENV{'HTTP_REFERER'}, если жертва перейдет по ссылке на нашу страницу, также необходим;

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

Затем, когда жертва заходит проверять почту, мы посылаем mail.ru запрос с куками жертвы и идентификатором. В течение получаса ящик будет в вашем распоряжении. Но я не утверждаю это, потому что сессия может быть привязана к IP, и тогда все накроется медным тазом (подмена IP-адреса – не такая простая задача). Наконец, мы начинаем примерно представлять схему работы идентификации.

n  При первоначальной аутентификации у клиента создается хэш (в куках), который зависит от: IP, времени, начала сессии, имени, пароля.

n  Хэш действует на протяжении одной сессии, в течение получаса (время зависит от вашего проекта) и отсылается при каждом запросе новой страницы вашего сайта. В данном случае возможна лишь аналогичная атака с mail.ru, но в составе с атакой spoofing, что реализуется несколько сложнее, и получение ответов от сервера затруднено принципом атаки (подмена IP).

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

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

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

Микро-система

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

<form action='cgi–bin/auth.cgi'>

<input name='login' type='text'>

<input name='password' type='password'>

</form>