Каковы подробности реализации и обоснование AntiForgeryToken ASP.NET MVC3? - PullRequest
Новая
       12

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

5 голосов
/ 06 февраля 2011

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

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

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

  1. Как внутренне работает AntiForgeryToken
  2. Что следует использовать для защиты
  3. Что НЕ следует использовать для защиты
  4. Каковы причины выбора реализации для # 1 выше?
    • Пример:
      • - это безопасная реализация от файлов cookie DoubleSubmit и других распространенных уязвимостей
      • Существуют ли проблемы с реализацией, если пользователь открывает несколько вкладок
      • Чтоделает реализацию MSFT отличной от той, что доступна на SANS

1 Ответ

1 голос
/ 28 марта 2011

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

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

Метод validate в основном десериализует значения из файла cookie и из формы и сравнивает их на основе значений (salt / value / ticks / username).

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

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

...