Каковы детали реализации и обоснование AntiForgeryToken ASP.NET MVC3?

AntiForgeryToken используется для предотвращения атак CSRF, однако ссылки в MSDN не дают мне подробного представления о том, что именно делает AntiForgeryToken, или как он работает, или почему все делается именно так.

Насколько я понимаю, он создает хеш внутри веб-страницы и файл cookie. Один или оба из них используют хеширование IPrincipal.Name и симметричное шифрование.

Может ли кто-нибудь пролить свет на:

  1. Как AntiForgeryToken работает внутри
  2. Что следует использовать для защиты
  3. Что НЕ следует использовать для защиты
  4. What is the reasoning behind the implementation choices for #1 above?
    • Example:
      • is the implementation safe from "DoubleSubmit" cookies and other common vulnerability
      • Есть ли проблемы с реализацией, если пользователь открывает несколько вкладок
      • Чем отличается реализация MSFT от той, что доступна на SANS

security csrf asp.net-mvc-3 antiforgerytoken
person halfbit    schedule 06.02.2011    source источник
comment
Вам интересно, что такое CSRF? Конкретно как MS с этим справляется? Или как бы вы вообще с этим справились?   -  person CtrlDot    schedule 23.03.2011
comment
@CtrlDot - я хотел бы узнать обо всех деталях реализации MSFT. Я могу перейти на security.stackexchange.com, чтобы получить много информации о CSRF и дважды отправить файлы cookie.   -  person halfbit    schedule 28.03.2011

Ответы (1)


arrow_upward
1
arrow_downward

Хорошо, вот мой лучший снимок.

1) Внутри mvc использует методы шифрования RNG для создания 128-битной строки, которая действует как токен XSRF. Эта строка хранится в файле cookie, а также в скрытом поле где-нибудь в форме. Имя файла cookie, по-видимому, имеет форму __RequestVerificationToken + версия пути к приложению в кодировке base 64 (на стороне сервера). В html-части этого используется AntiForgeryDataSerializer для сериализации следующих частей данных - соль - значение (строка токена) - тики даты создания - имя пользователя (похоже, Context.User)

Метод проверки в основном десериализует значения из файла cookie и из формы и сравнивает их на основе значений (соль / значение / тики / имя пользователя).

2/3) Я думаю, что это обсуждение больше касается того, когда использовать токены XSRF, а когда нет. На мой взгляд, вы должны использовать это в каждой форме (я имею в виду, почему бы и нет). Единственное, о чем я могу думать, что это не защищает, - это то, действительно ли вы попали в форму, о которой идет речь, или нет. Знание кодировки base64 имени приложения позволит злоумышленнику просмотреть файл cookie во время атаки XSRF. Может быть, моя интерпретация неверна.

4) Не уверены, что именно вы здесь ищете? Думаю, я бы создал механизм, в котором я бы попытался сохранить токен XSRF в сеансе (если он уже был доступен), а если нет, то попробую подход с использованием файлов cookie. Что касается типа используемой криптографии, я нашел это ТАК искусным. Плюсы и минусы RNGCryptoServiceProvider

person CtrlDot    schedule 28.03.2011