Согласно моим исследованиям, правильный способ защиты от этого — установить NONCE для каждого запроса GET, который возвращает форму, а затем проверить наличие NONCE в запросе POST. Тем не менее, кто-то все еще может написать сценарий, чтобы ПОЛУЧИТЬ мою форму вместе с NONCE, а затем отправить ее обратно с помощью NONCE.
Поскольку это такая широко известная уязвимость, не должны ли браузеры уже позаботиться об этом, запретив междоменные вызовы ajax? Если нет, то есть ли в ASP.NET MVC 4 встроенный механизм защиты от этого?
Должен ли я защищаться от подделки междоменных запросов?
Ответы (3)
Да, есть встроенный механизм. HtmlHelper.AntiForgeryToken, который может быть используется для защиты вашего приложения от подделки межсайтовых запросов. Чтобы использовать эту функцию, вызовите метод AntiForgeryToken из формы и добавьте атрибут ValidateAntiForgeryTokenAttribute для метода действия, который вы хотите защитить.
CSHTML-файл:
@Html.AntiForgeryToken()
Контроллер:
[ValidateAntiForgeryToken]
public ActionResult Edit(User updatedUser)
Вы заметите, что токен включает в себя две меры безопасности — поле формы и файл cookie:
Чтобы сгенерировать маркеры анти-XSRF, вызовите метод @Html.AntiForgeryToken() из представления MVC или @AntiForgery.GetHtml() со страницы Razor. Затем среда выполнения выполнит следующие шаги:
Если текущий HTTP-запрос уже содержит токен сеанса анти-XSRF (файл cookie анти-XSRF __RequestVerificationToken), токен безопасности извлекается из него. Если HTTP-запрос не содержит токена сеанса защиты от XSRF или извлечение токена безопасности завершается сбоем, будет создан новый случайный токен защиты от XSRF.
Маркер поля анти-XSRF создается с использованием маркера безопасности из шага (1) выше и удостоверения текущего вошедшего в систему пользователя.
Если на шаге (1) был сгенерирован новый токен анти-XSRF, будет создан новый токен сеанса, содержащий его, и он будет добавлен в коллекцию исходящих файлов cookie HTTP. Маркер поля из шага (2) будет заключен в элемент, и эта HTML-разметка будет возвращаемым значением Html.AntiForgeryToken() или AntiForgery.GetHtml().
Чтение:
person
MikeSmithDev
schedule
05.12.2013
Спасибо за руководство. Однако, кстати, как NONCE защитит меня, если злоумышленник все еще может заставить браузер сделать запрос GET, получить NONCE, а затем отправить форму с NONCE в ней?
- person AxiomaticNexus; 06.12.2013
@YasmaniLlanes, как вы думаете, как они это делают? Похоже, злоумышленник сидит за компьютером пользователя.
- person MikeSmithDev; 06.12.2013
Они могут обслуживать страницу в браузере с помощью JavaScript, который делает именно это.
- person AxiomaticNexus; 06.12.2013
Нет, нельзя: en.wikipedia.org/wiki/Same-origin_policy вы разрешили им использовать CORS
- person Stefan H; 06.12.2013
@YasmaniLlanes, если вы прочитаете ссылку в ответе StefanH, вы увидите, что
AntiForgeryToken состоит не только из поля формы, но и из файла cookie. Злоумышленник не сможет подделать или прочитать файл cookie, принадлежащий вашему домену.
- person MikeSmithDev; 06.12.2013
Эти одноразовые номера используются для защиты от подделок межсайтовых запросов. Для этого не требуется междоменный вызов ajax, и браузеры имеют защиту от них. CSRF — это уязвимость, потому что когда браузер вызывает ваш сайт, он отправляет информацию о сеансе для вашего сайта, независимо от страницы, которая сообщила браузеру о выполнении вызова. Браузеру можно указать сделать запрос на получение вашего site.com, включив тег img на evilsite.com, который указывает на страницу на вашем site.com. Если, когда этот запрос на получение обрабатывается yoursite.com, вы проверяете одноразовый номер, нет никакого способа, чтобы диск evilsite.com узнал этот одноразовый номер. Аналогичные вещи можно сделать и для почтовых запросов.
На этой странице, похоже, есть некоторая информация о том, как смягчить это в ASP.NET MVC: http://www.asp.net/mvc/overview/security/xsrfcsrf-prevention-in-aspnet-mvc-and-web-pages
Привет, Стефан
person
Stefan H
schedule
05.12.2013
Запросы GET не должны вызывать беспокойства, поскольку вы никогда не должны выполнять конфиденциальные задачи с запросами GET. POST-запросы - это то, о чем я беспокоюсь. Как NONCE защитит меня, если злоумышленник все еще может заставить браузер сделать запрос GET, получить NONCE, а затем отправить форму с NONCE в ней?
- person AxiomaticNexus; 06.12.2013
Потому что, когда выполняется получение (опять же, как тег изображения или что-то подобное), содержимое страницы на самом деле недоступно для вызывающей страницы, поэтому злая страница не может получить одноразовый номер.
- person Stefan H; 06.12.2013
Нет, если я сделаю запрос GET через тег
<img>, но я могу сделать запрос GET, используя AJAX и JSONP.
- person AxiomaticNexus; 06.12.2013
Хотя они не должны, они часто делают это. Например, к вашей странице выхода обращаются через get или post? Хотели бы вы, чтобы ваши пользователи выходили из вашего сайта, просто посещая форум или другой сайт, где злоумышленник может контролировать HTML-код?
- person Stefan H; 06.12.2013
И именно здесь вступает в действие защита браузера. Если вы не включили междоменные запросы на своем веб-сервере, вы должны быть защищены этим.
- person Stefan H; 06.12.2013
Моя страница выхода доступна через запрос GET, но это не то, что я бы назвал критическим. Кроме того, как сервер узнает, откуда приходит запрос? Отправляют ли браузеры домен, в котором они сейчас находятся, с каждым запросом, а я не знал об этом все это время?
- person AxiomaticNexus; 06.12.2013
Вы также должны взглянуть на концепцию защиты от CSRF без сохранения состояния. Для этого есть 2 стандартных подхода: шаблон зашифрованного токена и шаблон двойной отправки файла cookie. Шаблон зашифрованного токена использует токен, зашифрованный Rijndael, который содержит встроенное одноразовое значение, которое не может быть прочитано сценариями и является очень надежной криптографической структурой.
person
Paul Mooney
schedule
18.12.2013
Ваш шаблон стал частью рекомендации OWASP по предотвращению атак CSRF.
- person Code4R7; 29.01.2018
