Это уязвимость перехвата сессии?

У меня есть веб-приложение, которое отправляет этот cookie после входа в систему:

Set-Cookie: ASP.NET_SessionId=55adfqwdf6qdqrgsdfg; path=/; HttpOnly; SameSite=Lax

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

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

Получение этой строки злоумышленником — это похищение сессии. Копирование собственного cookie не является атакой или уязвимостью.

Это ожидаемое поведение. Сервер не знает, кто вы, для сервера cookie — это “вы”. Единственное, что идентифицирует вас, — это эта строка. Любой, обладающий этой строкой, — это “вы”.

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

Нет, это не так. Это похоже на то, как вы берете свои ключи от дома, идете к слесарю, создаете копию и заявляете, что замок вашей двери уязвим. Похищение сессии включает в себя получение злоумышленником этого cookie. Это может быть ошибка программирования на стороне фронтенда веб-приложения (XSS, CSRF) или бэкенда (SQL-инъекция, включение файлов, удаленное выполнение команд), также это может быть сетевую атаку (прослушка, MitM). HTTPS защитит от сетевых атак (прослушка, MitM), но не от XSS или атак на бэкэнд, и такие атаки более распространены.

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

Но перед тем, как подводить итог, я бы также проверил следующее:

• Новый токен сессии генерируется при аутентификации.
• Токен сессии имеет как минимум 64 бита энтропии.
• Токен сессии генерируется с использованием криптографически безопасного алгоритма.

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

• Установка атрибута ‘Secure’ для cookie сессии.
• Использование префикса ‘__Host-‘ для имени cookie.

Стандарты проверки безопасности приложений от OWASP предоставляют более полный список требований к безопасности, относящихся к управлению сессиями в разделе V3.

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

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

• Ваши настройки TLS могут быть небезопасными, особенно если вы используете более старые версии TLS до 1.3.
• Вы можете не строго применять HTTPS, позволяя злоумышленнику в положении man-in-the-middle получить токены из незашифрованного HTTP-трафика. Чтобы это исправить, вам нужен HTTP Strict Transport Security (HSTS), желательно с предварительной загрузкой.
• Вы можете обрабатывать закрытые ключи для TLS небезопасным образом, например, не шифруя их в состоянии покоя.
• Ваши настройки сервера могут быть небезопасными. Например, токены могут быть записаны где-то.
• С само приложение также может раскрыть токен.

Так что вы не можете просто сказать, что риск низкий, пока вы используете HTTPS. Вам нужно проверить всю систему.

Также обратите внимание, что существуют подходы для предотвращения того, чтобы злоумышленники просто брали украденный токен и использовали его самостоятельно. Например, Учетные данные сессии, привязанные к устройству (DBSC) привязывают токен к оборудованию, а Привязка токенов позволяет привязывать токены к соединениям TLS. Обратите внимание, что в обоих случаях поддержка браузером все еще ограничена.