Безопасность: ASp.NET Identity HTTPOnly Cookie с SSL

Question

Это общий вопрос, поскольку я использую объект User, хранящийся в сеансе, и я изучаю новую систему идентификации.

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

Все, что я изучил на этом, говорит, что httpOnly через SSL очень безопасен с точки зрения взлома. Я не решаюсь отправить что-либо, кроме идентификатора пользователя, чтобы идентифицировать пользователя, а затем найти остальное в БД, чтобы убедиться, что, если пользователь взломан, разрешения не будут взломаны. Я слишком осторожен?

Я также вижу, как люди устанавливают файлы cookie на срок до 7 дней или 1 день ... В отношении этого и вы отправляете разрешения/роли в области претензий. Что происходит, если они меняются на сервере. В принципе, кажется, что пользователю нужно будет войти в систему и выйти из системы, чтобы новые разрешения имели место. Интересно, что нормальное ожидание с программными стандартами UI?

Заранее спасибо за ваши мысли :)

Angela

Answer 1

Простите мое невежество, но я уже не попадается кусок программного обеспечения, где требования будут отправленного в печенье. Как правило, проблема с файлами cookie - это возможность атаки XSS (межсайтовый скриптинг), поскольку браузеры записываются так, чтобы их всегда отправлять.

В наши дни люди, как правило, используют механизм федеративной аутентификации, где Поставщик удостоверений (страница входа) и поставщик услуг (код приложения) не обязательно являются одним и тем же приложением и не всегда напрямую связаны между собой , Это означает, что данные пользователя, которые вы могли искать в db, существуют только в IdP, и SP должен иметь дело с тем, что предоставил IdP.

Именно поэтому каждый бит информации отправляется по требованию. Это означает, что IdP утверждает, что имя пользователя - john.smith, но SP может не иметь никаких средств для проверки этого.

Чтобы заставить его работать, IdP и SP должны были установить определенную форму доверия, как правило, в виде предварительно разделяемых ключей подписи, что позволяет IdP подписывать токен (например, конверт SAML или JWT) и SP чтобы проверить подпись, чтобы иметь возможность проверить, что токен не был подделан.

Как правило, этот токен никогда не используется в качестве файла cookie; вместо этого он добавляется в заголовок Authorization, обычно используя схему Bearer.

Кроме того, в качестве побочного примечания - когда вы говорите, что знакомы с сеансами, вы должны понимать, что трекер отслеживания также является файлом cookie (в ASP.NET). На сервере есть информация о пользователе, хранящемся в кеше памяти приложения, и браузер продолжает отправлять куки-сообщение «here i am». Таким образом, безопасность разумна, существует сопоставимый уровень между простым использованием файлов cookie или использованием cookie + сеанса. Конечно, можно утверждать, что куки-файл может утечка информации, но приложение всегда может маркировать данные или шифровать весь файл cookie, отрицающий этот аргумент.