Есть ли основания не доверять ASP.NET AntiForgeryToken? - PullRequest
Новая
       11

Есть ли основания не доверять ASP.NET AntiForgeryToken?

15 голосов
/ 27 марта 2012

Я знаю, что сайты Stack Exchange не используют встроенную в ASP.NET MVC @Html.AntiForgeryToken() для предотвращения атак XSRF / CSRF.Вместо создания скрытого ввода с именем __RequestVerificationToken со значением действительно длинное на основе раздела machineKey файла web.config, метод Stack Exchange создает вход с именем fkey с MUCH более краткое значение.Это, по-видимому, Guid, и, основываясь на свидетельствах проекта Stack Exchange Data Explorer в Google Code , это значение привязано к каждому отдельному пользователю, оставаясь достаточно постоянным до тех пор, пока вы не войдете или не выйдете.

Кроме того, значение Stack Exchange постоянно на странице и доступно клиентскому скрипту, так что Ajax публикует сообщения для голосования и тому подобное, также использует токен.В отличие от этого

Так почему же Stack Exchange марширует на своего собственного барабанщика?

  • Есть ли причина не доверять AntiForgeryToken?
  • Есть ли у AntiForgeryToken некоторые ограничения, которыекоманда Stack Exchange не желала принимать?Если да, то чем они были?
  • Или, может быть, AntiForgeryToken просто не было рядом (он начал свою жизнь в проекте MVC Futures), когда было запущено переполнение стека, и если бы у них было это с нуля сегодня, они бы использовалиAntiForgeryToken?

Мне не удалось найти ни одного сообщения в блоге от Джеффа или других сотрудников команды Stack Exchange, чтобы объяснить руководящие принципы, лежащие в основе политики предотвращения XSRF в сети SE.Было бы здорово, если бы кто-то из них мог написать рецензию, если, конечно, предположить, что это можно сделать в общих чертах, не создавая уязвимости.Это была бы действительно ценная информация для тех из нас, кто хочет обезопасить свои веб-сайты, но не совсем уверен, просто слепо доверяет Microsoft сделать это за нас.

1 Ответ

9 голосов
/ 18 апреля 2012

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

Мы реализовали подход, изложенный в этом CodeThinked блоге , и мы не могли быть счастливее. Похоже, Фил Хаак также поддерживает этот подход, основываясь на своем блоге октябрь 2011 года

Несколько (незапрошенных, я знаю!) Указателей:

  1. если вы работаете в веб-ферме, вам, конечно, следует использовать статический машинный ключ в вашем файле Web.config
  2. Убедитесь, что на всех ваших серверах установлен этот KB . В противном случае вы можете столкнуться с проблемами проверки машинного ключа
...