Я управляю довольно большим сайтом с тысячами посещений каждый день и довольно большой пользовательской базой. С тех пор, как я начал переходить на MVC 3, я разместил AntiForgeryToken в ряде форм, которые изменяют защищенные данные и т.д.
Некоторые другие формы, такие как вход и регистрация, также используют AntiForgeryToken, но я начинаю сомневаться в их необходимости по нескольким причинам...
Форма входа требует, чтобы пользователь знал правильные учетные данные. Я не могу придумать, как CSRF-атака может быть полезна здесь, особенно если я проверю, что запрос пришел с того же хоста (проверяя заголовок Referer).
Токен AntiForgeryToken генерирует разные значения при каждой загрузке страницы. Если у меня открыты две вкладки со страницей входа, а затем я попытаюсь опубликовать их, первая загрузится успешно. Вторая не загрузится с AntiForgeryTokenException (сначала загрузите обе страницы, а затем попытайтесь их опубликовать). Для более защищенных страниц - это, очевидно, необходимое зло, но для страниц входа - это кажется излишеством и просто напрашивается на проблемы.
Возможно, есть и другие причины, по которым следует использовать или не использовать маркер в своих формах. Правильно ли я понимаю, что использование маркера в каждой почтовой форме - это излишество, и если да, то какие формы выиграют от этого, а какие точно не выиграют?
P.S. Этот вопрос также задавался на StackOverflow, но я'не совсем убежден. Я решил задать его здесь, для большей безопасности.
Да, важно включать маркеры защиты от подделки для страниц входа в систему.
Почему? Потому что существует вероятность "атаки CSRF". При атаке CSRF атакующий вводит жертву на целевой сайт под учетной записью атакующего. Рассмотрим, например, атаку на Алису, которая является пользователем Paypal, со стороны злобной злоумышленницы Эвелин. Если Paypal не защитил свои страницы входа в систему от CSRF-атак (например, с помощью маркера защиты от подделки), то злоумышленник может молча войти через браузер Алисы в аккаунт Эвелин на Paypal. Алиса попадает на веб-сайт Paypal, и Алиса входит в систему, но входит как Эвелин. Предположим, что Алиса затем нажимает на страницу для привязки своей кредитной карты к счету Paypal и вводит номер своей кредитной карты. Алиса думает, что привязывает свою кредитную карту к своему счету Paypal, но на самом деле она привязала ее к счету Эвелин. Теперь Эвелин может покупать товары и списывать их с кредитной карты Алисы. Упс. Это тонкий и немного неясный момент, но достаточно серьезный, чтобы включить маркеры защиты от подделки для целевого действия формы, используемого для входа в систему. Более подробную информацию и некоторые реальные примеры таких уязвимостей см. в этой статье.
Когда можно обойтись без маркера защиты от подделки? В общем случае, если целью является URL, и обращение к этому URL не имеет побочных эффектов, то вам не нужно включать маркер защиты от подделки в этот URL.
Примерное правило: включать маркер защиты от подделки во все POST-запросы, но для GET-запросов он не нужен. Однако это грубое эмпирическое правило является очень грубым приближением. Оно предполагает, что все GET-запросы не будут иметь побочных эффектов. В хорошо спроектированном веб-приложении так и должно быть, но на практике иногда разработчики веб-приложений не следуют этому правилу и реализуют обработчики GET, которые имеют побочный эффект (это плохая идея, но это не редкость). Вот почему я предлагаю руководство, основанное на том, будет ли запрос иметь побочный эффект для состояния веб-приложения или нет, а не на GET vs POST.
Токен может понадобиться на странице входа в систему, если вам нужно предотвратить злоумышленный вход на сайт с определенными учетными данными. Я могу представить это в том случае, если кого-то подставляют для чего-то, что требует входа в систему под определенным пользователем. С учетом сказанного, это немного надуманный пример.