Как токен защиты от подделки MVC сохраняется между перезапусками веб-сервера?

Я реализовал защиту от подделки, используя ValidateAntiForgeryTokenAttribute в MVC 5. Она работает нормально, но в будущем мы можем перейти к подходу к хостингу, больше похожему на «веб-ферму». Если я запускаю свое приложение в процессе разработки и перехожу к форме, перезапускаю веб-сервер (путем перезапуска приложения в Visual Studio), а затем отправляю форму, оно не создает исключение System.Web.Mvc.HttpAntiForgeryException.

Наше приложение не использует никакого другого состояния сеанса. Может ли кто-нибудь помочь мне понять, как мой сервер продолжает работу с того места, где он остановился? Я не определяю machineKey в своем web.config или где-либо еще, что я могу найти. Это как-то связано с работой в среде разработки?

Единственные ссылки, которые я могу найти, относятся к более ранним версиям MVC, поэтому мне интересно, решается ли это по-другому сейчас.

Я рад, что эта функция работает, но мне нужно понять, почему.


asp.net-mvc asp.net-mvc-5 csrf antiforgerytoken
person DustinA    schedule 23.07.2014    source источник
comment
Для объяснения того, что происходит за кулисами: levelup.gitconnected.com /   -  person David Klempfner    schedule 27.01.2021

Ответы (1)


arrow_upward
3
arrow_downward

Сам сервер ничего не помнит; это не обязательно.

Здесь работают две вещи:

  • Скрытый ввод формы
  • куки

Это означает, что если пользователь посещает страницу с AntiForgeryToken на ней, то сервер перезагружается, это не проблема, потому что __RequestVerificationToken пользователя и формы остаются такими же, как и были.

Фактический токен безопасности – это хешированный ключ, который хранится внутри объекта AntiForgeryToken. Этот объект сериализуется в Base 64, и это то, что вы видите, когда смотрите на значения __RequestVerificationToken. Поскольку ключи безопасности сохраняются каждый раз, даже если сервер сбрасывает значения, они все равно остаются внутри этих объектов. Затем ключи извлекаются и сравниваются для проверки токенов.

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

person Rowan Freeman    schedule 23.07.2014
comment
Спасибо за это. Я знаю, что эти два значения сравниваются, но я думаю, что ключ шифрования, используемый для расшифровки значений, должен быть перегенерирован при перезапуске IIS. После этого он не сможет расшифровать значения, потому что ключ новый. - person DustinA; 24.07.2014
comment
А, я понимаю, о чем вы спрашиваете. Отличный вопрос. Я обновлю свой ответ. - person Rowan Freeman; 24.07.2014
comment
Я ценю время, которое вы потратили на написание этого ответа, но я не уверен, что он правильный. На этом веб-сайте Microsoft говорится, что полезная нагрузка токенов анти-XSRF зашифрована и подписана. Вот URL-адрес страницы: asp.net/mvc/обзор/безопасность/. Я считаю, что в моем случае происходит то, что MachineKey, используемый для шифрования и дешифрования, фактически не меняется между перезапуском веб-сайта или пула приложений, как это было раньше. Я пока не могу найти документацию, подтверждающую это, но я думаю, что это то, что происходит. - person DustinA; 30.07.2014
comment
Без проблем. Я только едва понимаю логику. Базовые алгоритмы — это алгоритмы хеширования (что-то вроде HMAC-SHA1). Однако я по-прежнему поддерживаю то, что считаю наиболее важным утверждением, а именно то, что ключи хранятся в токенах, которые хранятся в файле cookie и в форме ввода. Это означает, что их можно найти и сравнить. Надеюсь, кто-то сможет проверить или уточнить (Micrsoft ^^). - person Rowan Freeman; 30.07.2014