Безопасность сессий
Безопасность веб-сайтов основывается на управлении сессиями. Когда пользователь подключается к безопасному сайту, он предоставляет учетные данные, как правило, в форме имени пользователя и пароля. Веб-сервер не имеет представления о том, какой пользователь уже вошел в систему и как он переходит от страницы к странице. Механизм сессий позволяет пользователям не вводить пароль каждый раз, когда они хотят выполнить новое действие или перейти к новой странице.
В сущности, управление сессией гарантирует, что в настоящее время соединен тот пользователь, который проходил авторизацию. Но, к сожалению, сессии стали очевидной мишенью для хакеров, поскольку они могут позволить получить доступ к веб-серверу без необходимости проверки подлинности.
После аутентификации пользователя, веб-сервер предоставляет ему идентификатор сессии. Этот идентификатор хранится в браузере и подставляется всякий раз, когда нужна проверка подлинности. Это позволяет избежать повторяющихся процессов ввода логина/пароля. Все это происходит в фоновом режиме и не доставляет дискомфорта пользователю. Представьте, если бы вы вводили имя и пароль каждый раз, когда просматривали новую страницу!
Идентификатор сессии представляет собой строку символов или цифр. Сервер помнит, что идентификатор сеанса (SID) был дан пользователя и позволяет получить доступ. Как следствие, ID сессии имеет большое значение для идентификации, поэтому хакеры в течение многих лет искали пути обхода проверки подлинности.
Так как же получить ID сессии? Есть ряд методов используемых для получения идентификатора. Наиболее очевидным является атаки на сервер. Сервер где-то хранит SID и иногда это общедоступное для чтения место. Например, на некоторых хостингах для клиентских юзеров используется папка /tmp и каждый пользователь может просматривать ID сеансов.
Другой метод заключается в атаке на клиента. MSIE, например, имеет многочисленные недостатки, которые позволяют веб-сайтам читать куки, которые им не принадлежат. В идеале, только сайт, для которого созданы куки, должен иметь к ним доступ. К сожалению, это не всегда так, и есть множество случаев, когда печеньки становились общедоступными. Помимо этого, кэш браузера доступен любому, кто имеет доступ к этому компьютеру. К примеру, компьютер в интернет-кафе. В любом случае, куки постоянно хранятся в кэше браузера и являются заманчивой целью.
Следующий способ, который используется для кражи идентификатора сессии является угадывание. Прогнозирование происходит тогда, когда атакующих убеждается в связи между идентификаторами сеансов. Например, некоторые веб-системы используют приращение ID каждый раз, когда пользователь входит в систему. Зная одну сессию хакер может определить другую. Другой метод, атака "грубой силой" (brute force attack). Это простой, но потенциально эффективный метод для определения идентификатора сессии. Хакер перебирает все возможные идентификаторы сессий, пока случайно не встретит допустимый. Но это не является серьезной уязвимостью, поскольку обычно SID генерируется рандомно и перебор может занять довольно продолжительное время.
Что делать, чтобы смягчить атаки?
1. Всегда используйте надежное шифрование при передаче. Отказ от шифрования идентификатора сессии серьезно сказывается на безопасности системы. Кроме того, для сессий основанных на cookies используйте SSL, задав свойству RequireSSL значение true. Это уменьшит вероятность XSS атаки, поскольку страницы на незашифрованном разделе сайта будут не в состоянии читать куки.
2. Установите срок действия сессии. После определенного периода бездействия юзер автоматически отключается от сессии. Таким образом, сессия будет доступна лишь некоторое время, что уменьшает риск перехвата.
3. Никогда не делайте идентификаторы сессий видимыми. Это серьезная проблема для URL сессий. SID выступает в качестве GET переменной и находится адресной строке браузера. Используйте POST метод или cookie вместо GET.
4. Всегда выбирайте длинный ID сессии. Многие нападения происходят потому что SID слишком короткий или его легко предсказать. Идентификатор должен состоять из псевдо-случайных символов составленных с помощью ГСЧ. Например, при использовании 32-символьного идентификатора сессии, который содержит буквы алфавита и цифры от 0 до 9, число возможных идентификаторов равняется 2.27е57! Это эквивалентно 190 битному паролю и достаточно надежно для большинства веб-приложений, используемых сегодня.
5. Внимательно относитесь к критическим ситуациям. Сервер должен повторно проверять пользователя при попытке выполнения важных операций. Например, повторить ввод пароля при попытке его изменения.
6. Надежно закрывайте сессии. При закрытии сессии удаляйте идентификатор на сервере, а не полагайтесь на клиентскую сторону. Удаляйте SID при выходе.
7. Всегда предотвращайте кэширование страниц с конфиденциальной информацией на клиентской стороне. Используйте HTTP для установки срока, когда страница не кэшируется. Это заставит браузер отказаться от содержимого страницы из кэша.
8. Всегда требуйте повторной аутентификации после указанного периода, даже если сессия по прежнему активна. В противном случае, в случае захвата сессии злоумышленник может держать соединение открытым довольно долго.
9. Можно выполнять другие виды проверок. Например, можно использовать проверку SSL сертификата клиента и т.п.
В целом, веб-приложения останутся более менее защищенными с выполнением данных требований. Используете советы, описанные в данной статье, или же придумаете что-то свое.
