Предотвращение атак воспроизведения файлов cookie в ASP.Net MVC

Question

Мне было поручено реализовать пункт 4 в этой статье: http://support.microsoft.com/kb/900111

Это включает использование поставщика членства для добавления комментария к записям пользователей на стороне сервера при входе и выходе из него, а затем подтверждение того, что при использовании файла cookie для аутентификации пользователь не вышел из системы. Это имеет смысл для меня. То, что это начинает рушиться, - то, что мы в настоящее время не используем поставщика членства, и поэтому мне кажется, что я сталкиваюсь с переопределением всего нашего кода аутентификации, чтобы использовать поставщика членства. В настоящее время мы проверяем аутентификацию на контроллере и звоним FormsAuthentication.SetAuthCookie(), как только узнаем, что пользователь существует. Было бы много работы, чтобы заставить поставщика членства войти.

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

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

Answer 1

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

Да, вы можете сделать это. Поставщик членства хранит небольшой набор данных о пользователе (имя пользователя, адрес электронной почты, пароль, последний вход в систему, вопрос о потерянном пароле, ответ о потерянном пароле и т. Д.).

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

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

Answer 2

Я считаю, что MembershipProvider очень полезен. Это позволяет мне как разработчику использовать SQLMembershipProvider против локальной базы данных пользователей, а затем, когда я перехожу на работу, просто использовать ActiveDirectoryMembershipProvider, и мне не нужно менять строку кода (за исключением моего web.config файл).

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

Если вы решите перейти к схеме MembershipProvider, я не думаю, что вы пожалеете об этом. Это может быть болезненным в краткосрочной перспективе, но в долгосрочной перспективе, я думаю, вы увидите, что это окупилось. Поскольку в вашем контроллере уже написано много кода проверки подлинности, возможно, его будет не так сложно объединить с тем, как его использует MembershipProvider?

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

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