Короткий срок сессии не повышает безопасность

Я не знаю, откуда вдруг взялись "бесконечные" сессии у Гугла, и тем более AWS, возможно это про обычных пользователей, но у G Suite по умолчанию 14 дней, а в AWS вообще максимум 12 часов для SSO.

Все правильно, сессии никогда не должны истекать

Вложение

После логина в веб-приложение сессия не остаётся валидной навечно. Обычно срок сессии истекает спустя заданное время после логина или после того, как пользователь ничего не делал в течение какого-то времени. Какими должны быть эти сроки?

Введение

В некоторых веб-приложениях сессии имеют ограниченный срок. Спустя какое-то время пользователь разлогинивается и должен заново пройти аутентификацию. Для безопасности рекомендуют использовать достаточно быстрые таймауты сессий, например, выход через пятнадцать минут неактивности. Однако большинство мобильных приложений и больших веб-приложений наподобие Gmail или GitHub не придерживаются этой рекомендации. Похоже, что после логина сессия продолжается бесконечно и аутентификацию проходить больше не нужно. Такие приложения небезопасны? Умнее ли Google и Microsoft, чем NIST и OWASP?

Модель угроз

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

Однако можно ли предотвратить захват сессии, сделав так, чтобы её срок истекал через пятнадцать минут неактивности?

XSS

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

Токен логина

Если нападающий видит токен старой сессии в логах или на жёстком диске после кражи вашего компьютера, то таймаут сессии, вероятно, предотвратит захват сессии. Это аргумент в пользу таймаутов сессий, но необязательно в пользу коротких таймаутов. Кроме того, от такого лучше защищаться, обеспечив безопасность логов или шифрование жёсткого диска.

Общедоступные компьютеры

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

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

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

У нападающего есть доступ к устройству жертвы

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

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

Единственная ситуация, в которой немедленный доступ к веб-приложению всё-таки можно предотвратить: если у вас включена 2FA и вы взяли телефон или yubikey с собой на обед. Но даже в этом случае нападающий может установить браузерное расширение, которое отправит ему ваши учётные данные при следующем процессе логина.

Повторная аутентификация рискованна

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

Вывод

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

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

Кроме того, маленькие таймауты сессий снижают безопасность и удобство пользования.

Срок сессий Facebook*, Google, Amazon и GitHub никогда не истекает. Они считают, что это приемлемый риск, и мне кажется, они правы.

Meta Platforms*, а также принадлежащие ей Facebook и Instagram :
* признана экстремистской организацией, её деятельность в России запрещена;
запрещены в России.