Любая причина не доверять ASP.NET AntiForgeryToken?

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

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

Итак, почему Stack Exchange подходит к своему барабанщику?

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

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

Ответы

Ответ 1

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

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

Пара (незапрашиваемых, я знаю!) указателей:

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