ASP.NET MVC 4 WebAPI - нормально ли использовать состояние сеанса для защищенных ресурсов?

Question

Мы создаем трехуровневое веб-приложение с ASP.NET MVC посередине. Мы используем комбинацию прямых MVC и WebAPI для быстрого реагирования. Внутренние данные защищаются с использованием службы токенов .

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

Мы сохраняем сгенерированный токен в состоянии сеанса для простоты и гибкости. Нам нужно будет требовать состояние сеанса даже для вызовов WebAPI, чтобы мы могли получить доступ к этому токену для вызовов WebAPI. Перед доступом к ресурсам REST нам требуется аутентификация.

Я прочитал много сообщений на SO, которые заставляют это звучать, как будто это плохой подход. Каковы альтернативы ? и что было бы реальным ограничения этого решения?

Заранее благодарен за ввод

Answer 1

Сессия относительно легко скомпрометирована. Шифрование отсутствует (хотя вы можете указать, что это безопасный файл cookie, который помогает) cookie сеанса, или подтверждение, что оно действительно. Это делает относительно легким украсть и/или атаковать.

Кроме того, сеанс не идеален по многим другим причинам, например, всякий раз, когда рабочий процесс asp.net перерабатывается, сеанс будет потерян. Это заставит пользователя повторно войти в систему. Таким образом, сеанс может быть потерян случайно, в любое время, потому что вы не можете контролировать, когда рабочий процесс перерабатывается (он может сделать это по разным причинам).

Я действительно не знаю деталей вашей системы токенов, поэтому трудно предложить альтернативы, но вы можете посмотреть, как FormsAuthentication генерирует auth cookie в качестве основы. Вы также можете использовать FormsAuthentication и хранить свой токен в пользовательских данных билета.

Answer 2

Вам необходимо подумать, может ли система быть скомпрометирована из-за разделения аутентификации и сеанса, поскольку ASP.Net хранит идентификатор сеанса в виде отдельного файла cookie для файла cookie аутентификации.

Возьмите это слишком упрощенный пример:

Вы хотите, чтобы заставить пользователя изменить свой пароль, без исключений, на первом входе человека, поэтому в коде вы установите Session["MustCheck"] = true на Логин.

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

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

Там в настоящее время нет «MustCheck» и таким образом, пользователь может полностью избежать его

Если вы хотите делать что-то, что охватывает все базы, куки-это путь.

Вы можете использовать что-то вдоль линий encypting the value of the cookie, где вы шифруете значение с помощью A PROVEN METHOD (не используйте свои собственные!).

подтвержденный идентификатор пользователя или что-то неизменяемое (ID), относящееся к пользователю в качестве ключа.

Вы также можете использовать один из