Безопасность сайта. Защита сессии

Вольный перевод статьи "Security for Websites - Breaking Sessions to Hack Into a Machine", нашел здесь. Речь пойдет о безопасности сайта со стороны сессий. Правильный подход к управлению сессиями, возможные методы взлома, обхода аутентификации. Рекомендации к созданию и защите ID сессий.

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

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

Типичный сценарий: пользователь логинится на онлайн-сервисе. Когда он пройдет аутентификацию, веб-сервер закрепляет за пользователем "id сессии". ID - identification, идентификация - числовой и/или буквенный код, уникальный в пределах зоны действия (прим. переводчика). Этот ID хранится браузером и подставляется в запросы, когда требуется аутентификация. Такой подход позволяет избежать повторного ввода логина/пароля снова и снова. Все происходит в фоновом режиме, невидимо для пользователя, создавая больше удобства веб-серфинга в целом. Представьте, как было бы напряжно вводить логин/пароль при каждом переходе на новую страницу!

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

Так как же заполучить ID сессии? Есть ряд методов, используемых злоумышленниками для компромата ID сессии. Наиболее очевидный способ - атака на сервер. Сервер часто где-нибудь хранит ID сессий, хуже того, иногда сервер хранит SID-ы в общедоступном для чтения месте. Для примера, PHP хранит их в переменных сессий во временном каталоге [/tmp] (применительно к Nix-системам). Этот каталог общедоступен для чтения, т.е. любой пользователь системы легко может посмотреть ID сессий через базовые утилиты, являющиеся частью Unix API. Это серьезный риск, в частности на расшаренных хостах, где заведено много пользователей. Эта проблема с тех пор закрыта, но это лишь один пример.

Другой метод - атака на клиента. MS Internet Explorer, к примеру, имел многочисленные недостатки, которые позволяли сайтам читать чужие куки (cookies, "печеньки"), часто используемые для хранения SID. По идее, только сайт создавший "печеньку", должен иметь к ней доступ. К сожалению, это не всегда так, существует множество примеров куки с открытым доступом для всех. Самый яркий пример: кеш браузера часто доступен всем, кто имеет доступ к компьютеру. Это может быть хакер, взломавший комп жертвы другой атакой, или компьютер с публичным доступом в Интернет-кафе или киоске. В любом случае, куки в кеше браузера - заманчивая цель.

Не зашифрованные передачи не редкость и они допускают соединения, которые может использовать злоумышленник. Если не использовать HTTPS-протокол (шифрованный HTTP), ID сессии можно перехватить при передаче и использовать повторно. Во избежание элементарно можно отмечать куки, как "защищенные", таким образом они могут передаваться только по HTTPS. Только разработчики так поступают редко. Такая простая вещь может так далеко пойти (?? не понял смысла).

Другой путь компромата ID сессии - попытаться ее угадать. Прогнозирование работает, когда хакер видит шаблон в формировании ID сессий. К примеру, некоторые веб-системы увеличивают SID каждый раз, когда логинится пользователь. Зная один ID сессии можно хакнуть пользователей, вошедших до и после него. Другой подход - атака перебором (brute force). Это достаточно простой эффективный метод определения идентификатора сессии. Атака перебором происходит, когда взломщик перебирает сессионные идентификаторы, пока какой-нибудь не совпадет. А поскольку это не сложно, это очень эффективный способ.

Как предотвращать эти атаки?

1. Всегда используйте сильное шифрование во время передачи. Ошибка зашифровки идентификатора сессии может указывать на то, что онлайн-система небезопасна. В дополнение, для сессий основанных на куки, поднимайте флаг "SSL-only"(только SSL). Это немного усилит защиту. Такое указание уменьшит шанс того, что XSS-атака сможет захватить SID, поскольку страницы из не шифрованного раздела сайта не смогут прочитать куки.
2. Назначайте сессиям короткий срок жизни. Принудительно отключайте пользователя после короткого периода бездействия. В таком случае брошенная (не востребованная) сессия будет жить короткое время, а это уменьшает шанс того, что взломщик сможет вычислить активную сессию. Так же это весьма мудрый способ избежать постоянного подключения пользователя. Постоянные соединения обычно оставляют идентификатор сессии (или хуже, логин и пароль) в куки, размещенной в кеше пользователя. Это существенно уменьшает возможность взломщика получить правильный SID.
3. Никогда не делайте ID сессии видимым. Это главная проблема в GET-методе. Переменные GET всегда присутствуют в адресной строке браузера. Вместо этого используйте POST, куки или чаще заменяйте текущий SID другим значением.
4. Всегда создавайте сложный (сильный) идентификатор сессии. Многие атаки становятся возможными из-за слишком коротких или легко предсказуемых SID-ов. Идентификатор должен быть псевдо-случайным, полученным с помощью генератора случайных чисел. К примеру, идентификатор длиной 32 символа, состоящий из букв A-Z, a-z и 0-9 имеет 2.27E57 вариантов. Такой SID эквивалентен паролю длиной в 190 бит и является достаточно сильным для большинства веб-приложений.
5. Всегда дважды проводите проверку критических операций. Сервер должен требовать повторной авторизации, если пользователь пытается выполнить критически важную операцию. Например, если он хочет сменить пароль, то нужно требовать сначала ввести старый пароль.
6. Всегда отключайте пользователя безопасным методом. Выполняйте процедуру отключения так, чтобы сервер деактивировал сессию не полагаясь на то, что клиент удалит информацию о сессии. Удаляйте SID при отключении. Некоторые приложения даже принудительно закрывают браузер, чтобы наверняка закрыть сессию и удалить ее ID.
7. Всегда предотвращайте кеширование на стороне клиента, если на страницу выдается деликатная (конфиденциальная) информация. Через HTTP установите срок актуальности страницы так, чтобы она не кешировалась. Установка срока страницы в прошедшее время заставит браузер не кешировать страницу.
8. Всегда требуйте от пользователя повторную аутентификацию по прошествии определенного периода, даже если сессия все еще активна. Тогда даже в случае взлома активная сессия не сможет продолжаться. Иначе взломщик может поддерживать соединение открытым достаточно долго после успешной атаки на SID.
9. Существует еще несколько разумных проверок. Для примера, можно анализировать адресную строку браузера, проверять сертификаты SSL-клиента и до некоторой степени следить за IP-адресом. Подобные методы дают общую уверенность в том, что клиенты на самом деле те, кем представляются.

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

Статья выжила после слияния сайтов, подробности здесь. Дата первой редакции: 12 апреля 2011