Я знаю, что сайты Stack Exchange не используют встроенный ASP.NET MVC @Html.AntiForgeryToken() для предотвращения атак XSRF/CSRF. Вместо создания скрытого ввода с именем __RequestVerificationToken с действительно длинным значением на основе machineKey раздела web.config, метод Stack Exchange создает вход с именем fkey с более кратким значением MUCH. Это, по-видимому, руководство, и на основании данных из Stack Exchange Data Explorer project on Google Code это значение привязывается к каждому отдельному пользователю, оставаясь довольно постоянным до тех пор, пока вы не войдете в систему или не выполните вход.Любые причины не доверять ASP.NET AntiForgeryToken?
Кроме того, значение Stack Exchange является постоянным на странице и становится доступным для клиентского скрипта, так что сообщения Ajax для голосования и подобные вещи также используют токен. В отличие от
Так почему же Stack Exchange марширует на собственный барабанщик?
- Есть ли причина не доверять AntiForgeryToken?
- Имеет ли AntiForgeryToken некоторые ограничения, которые команда Stack Exchange не желала принимать? Если да, то какие?
- Или, может быть, AntiForgeryToken просто не было (он начал жизнь в проекте MVC Futures), когда Stack Overflow был запущен, и если бы им пришлось делать с нуля сегодня, они использовали бы AntiForgeryToken?
Мне не удалось найти какие-либо записи в блоге от Джеффа или других сотрудников команды Stack Exchange, чтобы объяснить основные принципы, лежащие в основе политики предотвращения XSRF в сети SE. Было бы очень приятно, если бы один из них мог написать рецензию, предполагая, конечно, что это можно сделать в общих чертах, не создавая уязвимости. Это было бы очень ценной информацией для тех из нас, кто хочет сделать наши сайты безопасными, но не совсем удобными, просто слепо доверяя Microsoft, чтобы сделать это за нас.
вариант 3: это было не вокруг, когда мы строили SO в 2008-2009 годах. Я не могу прокомментировать плюсы и минусы встроенного метода, потому что я никогда не использовал его. –
Другое соображение состоит в том, что любой механизм безопасности, который мы помещаем в MVC или ASP.NET, должен быть универсальным. Мы можем поразить 95% -ный случай, но всегда будет какой-то набор клиентов, у которых есть чрезвычайные требования, которые не может надеяться удовлетворить встроенный механизм общего назначения. Например, существующая реализация анти-XSRF является недружественной для сайтов, которые сильно используют JSON или идентификаторы, основанные на утверждениях, и в этих случаях разработчик в большинстве случаев откатывается от своего собственного решения. – Levi