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

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

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

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

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

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

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

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

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


person ElHaix    schedule 02.01.2012    source источник


Ответы (1)


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

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

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

person tvanfosson    schedule 02.01.2012
comment
Я на самом деле уже делаю что-то подобное. При каждом запросе создаются два новых идентификатора GUID. Первый GUID относится к пользователю и считывает файл cookie на стороне клиента. Если GUID этого посетителя уже существует в моей БД, я использую его значение. Если нет, установите cookie и добавьте его в БД. Второй GUID используется для отслеживания их сеанса (срок действия истекает через 3 минуты). Мне интересно, достаточно ли этих двух в сочетании или следуйте рекомендациям, в этом случае создайте третий GUID, который является средством проверки запроса (если я вас правильно понял)? - person ElHaix; 02.01.2012
comment
Я не говорю, что это строго необходимо, но это закрывает дыру, из-за которой запрос может быть повторен случайно, а также значительно затрудняет подделку запроса. Ни один из двух ваших GUID этого не делает. Успешный злоумышленник может отправить тысячи запросов с перехваченными идентификаторами GUID пользователя/сеанса за 3 минуты. Вам придется взвесить риск того, что это произойдет, и сложность добавления дополнительного одноразового одноразового номера. - person tvanfosson; 02.01.2012
comment
Имеет смысл. Я добавлю этот подход, а также концепцию использованного/неиспользованного. Спасибо. - person ElHaix; 02.01.2012
comment
если бы у нас были встроенные одноразовые токены. Я думаю, пришло время добавить это на mvcsecurity.codeplex.com - person Adam Tuliper - MSFT; 02.01.2012
comment
@AdamTuliper - На самом деле это было бы неплохо. Я думаю о реализации прямо сейчас, и проблема, которую я предвижу, заключается в том, что моя таблица RequestToken станет довольно большой, поскольку каждый запрос будет иметь запись, содержащую GUID. Как вы думаете, при скольких записях было бы безопасно очистить таблицу? Оставить его заполненным, скажем, 100 000 строк токенов запросов с истекшим сроком действия? - person ElHaix; 02.01.2012
comment
это (и реализация) зависит от вас. Вы можете очищать ежедневно. Предпочтительно вам может понадобиться другой кеш, чтобы помочь при загрузке БД. Посетите github.com/enyim/EnyimMemcached, например, для реализации memcache, чтобы снизить нагрузку на БД . - person Adam Tuliper - MSFT; 02.01.2012