Имеет ли смысл помещать antiforgerytoken в _Layout.cshtml?

Я разрабатываю приложение ASP.NET MVC и планирую защитить каждый запрос без GET (POST, PUT, DELETE и т. д.) с помощью AntiForegeryToken.

Я реализовал расширение классической проверки AntiForgery на основе [__RequestVerificationToken], отправленного в заголовке. Это потому, что большинство моих вызовов являются асинхронными ($.ajax()), и мне проще отправить значение скрытого поля таким образом.

Имеет ли смысл помещать один единственный @Html.AntiForgeryToken() в _Layout.cshtml (шаблон для всех страниц) и всегда ссылаться только на него?

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

Может ли кто-нибудь прояснить это для меня?

Спасибо

Лоренцо


security ajax asp.net-mvc csrf antiforgerytoken
person l.raimondi    schedule 15.11.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вы можете поместить его в свой _Layout.cshtml и сгенерировать один токен при отображении страницы, это нормально.

Несмотря на то, что использование разных токенов для каждого запроса имеет очень небольшое преимущество в плане безопасности, если ваш токен имеет достаточную энтропию (как и стандартный токен, сгенерированный @Html.AntiForgeryToken()), то для злоумышленника практически невозможно угадать токен даже во время сеанса пользователя. Таким образом, в большинстве случаев один токен на сеанс пользователя по-прежнему считается безопасным.

На самом деле, попытка использовать новый токен для каждого запроса приводит к всевозможным ошибкам в тяжелом приложении Javascript, потому что браузеру требуется существенное время, чтобы фактически изменить такие вещи, как значение cookie или отправить запрос, и частые запросы ajax приведет к состоянию гонки, и вам будет сложно отлаживать ошибки, связанные с несоответствием токенов.

В этом отношении ASP.NET MVC по-прежнему фокусируется на традиционных приложениях на основе форм, и хотя вы можете использовать его для предотвращения CSRF в современных приложениях с большим объемом Javascript с некоторыми настройками (например, настраиваемый атрибут для фактической проверки токена, отправленного в заголовках запроса), вам нужно написать некоторый собственный код, чтобы сделать это. Надеюсь, Microsoft добавит встроенную поддержку в будущих версиях.

ОБНОВЛЕНИЕ

После реализации решения с помощью @Html.AntiForgeryToken() непосредственно на странице шаблона (_Layout.cshtml) я обнаружил возможную проблему, связанную с использованием пользовательских утверждений. Проблема возникает во время повторной проверки UserIdentity. В качестве ссылки я оставлю ссылку на другой пост, в котором я имел дело с этим и добавил туда обходной путь для тех, кто выбирает ту же реализацию. Пользовательские претензии, потерянные при повторной проверке личности

Надеюсь, поможет !

person Gabor Lengyel    schedule 15.11.2016
comment
Итак, если я правильно понял: с точки зрения безопасности это нормально, но может вызвать несоответствие проверки токена (и, следовательно, ошибки!), потому что браузеру требуется некоторое время, чтобы настроить всю среду (скрытое поле + файл cookie), и мои запросы могут начаться раньше все улажено. Я правильно понял? - person l.raimondi; 15.11.2016
comment
Извините за путаницу. Иметь один токен в вашем макете и использовать его в запросах Javascript — это нормально и, вероятно, лучшее, что вы можете сделать. Наличие его где-то еще, например, отдельных токенов для отдельных форм или даже нового токена для каждого запроса, приведет к трудностям. Надеюсь, это прояснит ситуацию. :) - person Gabor Lengyel; 15.11.2016
comment
Так есть ли проблема с пользовательскими утверждениями или не о чем беспокоиться, если мы добавим их на уровне макета? - person love2code; 16.10.2019