Мы используем Microsoft.Owin.Security.Cookies.CookieAuthenticationProvider
в веб-приложении ASP.Net MVC.
Код входа в систему использует специальный класс, который отслеживает информацию авторизации (userRights
в примере ниже). Код выглядит так:
string auth = JsonConvert.SerializeObject(userRights);
ClaimsIdentity identity = new ClaimsIdentity(new[]
{
new Claim(ClaimTypes.AuthorizationDecision, auth),
}, DefaultAuthenticationTypes.ApplicationCookie);
AuthenticationManager.SignIn(identity);
Меня беспокоит то, что эта информация может храниться в файле cookie аутентификации и отправляться клиенту, где она потенциально может быть изменена или изменена.
Исходный код отлично скрывает происходящее. В VisualStudio «Перейти к реализации» говорится, что он не может найти никакой реализации IAuthenticationManager.SignIn
, а исходный код Microsoft.Owin.Security.Cookies.CookieAuthenticationProvider
просто показывает группу делегатов Action
, которые я не могу отладить, так как у меня нет символов.
Еще одна проблема - Атаки воспроизведения файлов cookie. Я думаю о решении обеих потенциальных проблем, используя хранилище сеансов следующим образом:
Session.Add("AuthorizationDecision", userRights);
и при выходе:
Session.Clear();
Session.Abandon();
AuthenticationManager.SignOut();
Таким образом, я могу быть уверен, что информация не доходит до клиента и не может быть там обработана. Но я могу что-то упустить, или мои первоначальные опасения могут не иметь оснований (которые я не могу проверить из-за непонятного кода). Наша команда обеспокоена тем, что «сеанс не предназначен для авторизации и не может быть зашифрован или так безопасен, как использование утверждений». Было бы здорово, если бы вы, эксперты, могли поделиться своими мыслями или снять мои опасения, объяснив, где хранятся утверждения.
-- РЕДАКТИРОВАТЬ --
Я пошел дальше и удалил авторизацию из утверждений аутентификации (поскольку никто, кажется, не знает, где хранится информация). Его можно кэшировать в сеансе, но у сеанса есть полностью независимый срок жизни по сравнению с файлом cookie, поэтому необходима проверка нуля, а также проверка ClaimsIdentity.IsAuthenticated
, если сеанс не является нулевым.
были те же вопросы относительно того, где хранятся данные о претензиях. относительно вашего беспокойства:
My concern is that this information may be stored inside the authentication cookie and sent to the client where it could potentially be manipulated or changed.
Файлы cookie зашифрованы и подписаны, поэтому данные нельзя ни просмотреть, ни подделать на стороне клиента.
Спасибо, вы явно не говорите, что
userRights
хранятся в cookie, но если они есть, они безопасны ... Что ж, я думаю, есть еще достаточно причин, чтобы хранить их где-нибудь на стороне сервера. Например, при изменении прав кэш может быть обновлен без необходимости выхода пользователя и повторного входа в систему. Но ваша точка зрения снимает беспокойство о манипуляциях с клиентами.