Мы пишем мобильное приложение iOS в objective-c, которое делает сообщения в нашем приложении ASP.NET MVC. На iPhone, стек HTTP (и файлы cookie и т.д.), По-видимому, используются совместно с Safari. Это оставляет нас открытыми для атак XSRF, поэтому, если я не ошибаюсь, нам нужно защитить POST с помощью анти-поддевных токенов и защитить наши методы контроллера с помощью ValidateAntiForgeryTokenAttribute.
Я рассмотрю этот вопрос, сказав, что я не правильно понимаю механизм, с помощью которого генерируются и проверяются токены антифригии... в частности, термин "nonce", используемый в этом контексте, несколько мистический.
Поскольку мы не доставляем HTML клиенту, мы не можем использовать стандартный @Html.AntiForgeryToken(), поэтому вместо этого мы должны использовать AntiForgery.GetTokens для приобретения и распространять токены нашим клиентам. У этого есть таинственный первый параметр: oldCookieToken. На данный момент я просто установил его null, и все, кажется, работает нормально. Так может ли кто-нибудь сказать мне... зачем использовать старый токен для алгоритма генерации токена? Если только один токен выдается нашему приложению iOS и повторно используется для нескольких сообщений, это будет проблематично?
AntiForgery.GetTokens будет пытаться повторно использовать старый токен cookie для целей проверки. Поэтому, если у вас уже есть токен проверки, который вы хотите повторно использовать, он попытается использовать его вместо создания нового. Если старый токен недействителен, он будет генерировать новый и использовать его вместо этого.
Итак, допустимо прохождение null до oldCookieToken. Он просто сообщает GetTokens всегда генерировать новый токен cookie.