Использование MVC3 AntiForgeryToken в сценариях без проверки подлинности? - PullRequest
Новая
       2

Использование MVC3 AntiForgeryToken в сценариях без проверки подлинности?

0 голосов
/ 02 января 2012

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

У меня есть приложение, которое публикует некоторыеинформация для mysite.com с site1, site2, site3 и т. д. У каждого сайта есть уникальный идентификатор, который отправляется в запросе POST через асинхронный POST Javascript.Javascript, который выполняется на сайте 1-3, создается на сайте mysite.com, а затем возвращается на сайты с некоторыми заполненными переменными Javascript.

Таким образом, жизненный цикл выглядит следующим образом:

  1. Страница на сайте site1 содержит ссылку на Javascript на mysite.com.
  2. Эта ссылка ссылается на маршрут контроллера, который генерирует Javascript для возврата на сайт 1.
  3. Конец возвращаемого JS содержит запрос POST, который возвращается на mysite.com, содержащий Url,браузер и т. д., подробности для посетителя страницы на сайте 1.

Я могу прекрасно прочитать параметры POST в принимающем контроллере из запроса JS POST, однако, то, что я хотел знатьесли есть смысл добавить маркер защиты от подделки в список параметров.

Если это так, мне нужно будет сгенерировать его при первоначальном запросе и передать обратно как переменную JS в JS, возвращенном на site1., затем передайте его обратно вместе с формой POST во втором запросе.

Поскольку любая обработка на mysite.com будет выполняться только в том случае, если найдена действительная учетная запись, есть ли смысл проходить через это?

Если это так, как мне сгенерировать токен защиты от подделки на уровне контроллера?

1 Ответ

0 голосов
/ 02 января 2012

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

Однократный случайный одноразовый номер может быть лучшим решением.Это затруднило бы подделку запроса и предотвращение ошибочной множественной отправки, скажем, от пользователя, использующего кэшированную копию.Создайте случайное значение (GUID может работать) на mysite.com, вставьте его в базу данных и отметьте как неиспользуемое.Отправить его обратно с постом.Проверьте, было ли оно использовано или нет.Если он не используется, отметьте его как использованный и выполните действия по регистрации.Если он уже использовался, отклоните запрос как дублирующую отправку.

Обратите внимание, что для этого вам не понадобится POST, достаточно простого GET с параметрами URL, поскольку одноразовый номер не допуститслучайно повторяется.

...