Предотвращает ли AntiForgeryToken в ASP.NET MVC защиту от всех атак CSRF?

Question

Использование AntiForgeryToken требует, чтобы каждый запрос передавал действительный токен, поэтому вредоносные веб-страницы с простым сценарием, отправляющим данные в мое веб-приложение, не будут работать.

Но что, если злонамеренный скрипт сначала сделает какой-то простой запрос GET ( Ajax ), чтобы загрузить страницу, содержащую маркер защиты от подделки, в скрытое поле ввода, извлечь ее и использовать для действительный POST ?

Это возможно, или я что-то упустил?

Answer 1

Да, это все, что вам нужно сделать.

Пока вы генерируете новый токен на каждой защищенной странице, с <%= Html.AntiForgeryToken() %> и всегда проверяйте его в любом защищенном действии, используя [ValidateAntiForgeryToken]

Это реализует шаблон токена синхронизатора, как описано в Шпаргалке по профилактике CSRF в OWASP.

Чтобы скрипт мог успешно выполнить приемлемый запрос, он должен сначала получить форму и прочитать токен, а затем опубликовать токен. Одинаковая политика происхождения остановит это в браузере. Сайт не может сделать http-запрос в стиле AJAX на другой сайт; только себе. Если по какой-либо причине такая же политика происхождения может быть нарушена, вы станете уязвимыми.

Обратите внимание, что если у вас есть уязвимость межсайтового скриптинга, то злоумышленник может использовать уязвимость xss, чтобы обойти защиту, обеспечиваемую той же политикой происхождения (поскольку сценарий теперь выполняется с вашего собственного сайта, поэтому SOP завершается успешно). Впрыснутый сценарий может затем успешно прочитать и повторно передать токен. Этот метод защиты от CSRF через XSS в последнее время часто встречается у некоторых червей. По сути, если у вас есть XSS, ваша CSRF-защита - пустая трата времени, поэтому убедитесь, что вы не уязвимы ни к одному из них.

Еще одна вещь, на которую стоит обратить внимание - это Flash и Silverlight. Обе эти технологии не подписываются на одну и ту же политику происхождения и вместо этого используют файлы междоменной политики для ограничения доступа к удаленным ресурсам. Сценарий Flash / Silverlight может получить доступ к ресурсам на вашем сайте только в том случае, если вы публикуете XML-файл междоменной политики на своем собственном сайте. Если вы публикуете этот файл, разрешайте только белый список доверенных сторонних серверов и никогда не разрешайте *.

Узнайте больше о CSRF на OWASP См. Также: Шпаргалка по профилактике XSS

Answer 2

Но что, если вредоносный скрипт сначала выполнит простой запрос GET (от AJAX), чтобы загрузить страницу, содержащую маркер защиты от подделки, в скрытое поле ввода, извлечь ее и использовать для создания действительного POST?

Да, это правда, но, если это не заканчивается в браузере, это не атака CSRF.

Если это завершит работу браузера (например, просмотр через HTTP-запрос в коде на стороне сервера), то, что случится, код очистки получит токен CSRF. Однако ваши законные, прошедшие проверку пользователи получат другой токен на своей машине. Поскольку токен, который поднимает скребок, отличается от того, который выдан вашим пользователям, то POST не будет выполнен.

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