День триста девяносто девятый. #АтакиНаСайты
ASP.NET MVC 5. Безопасность Веб-Приложений
2. Cross-Site Request Forgery (CSRF)
Подделка межсайтовых запросов (CSRF или XSRF) немного более сложная, чем XSS. Рассмотрим случай XSS + Confused Deputy. Проблема Confused Deputy заключается в подозрительном доверии приложений к принимаемым данным. Атаке подвергается ваш браузер, которого обманом заставляют представлять вас на удалённом веб-сайте.
Например, вы обнаружили уязвимость для XSS на «Популярном Сайте». Кроме того, допустим, что один «Крупный Банк» предлагает простой способ перевода денег онлайн с указанием параметров в URL:

https://bank.example.com?function=transfer&amount=1000&toaccount=23234554333&from=checking

Это может показаться чрезвычайно глупым. Какой банк в здравом уме так сделает? К сожалению, ответ на этот вопрос: «тысячи их» (с). Причина довольно проста: веб-разработчики слишком сильно доверяют браузеру, а публичность URL-адреса основана на том, что запрос может выполняться «скрыто» через AJAX, а сервер будет проверять личность пользователя, используя информацию из cookie-файла сеанса.

Дальше немного социальной инженерии. Вы заходите на «Популярный Сайт» и оставляете пост:
Эй, а знаете ли вы, что у клиентов «Крупного Банка» сумма цифр номера счета равняется 30? Смотрите сами: https://bank.example.com
Затем вы входите под другим аккаунтом, оставляя комментарий вроде:
Фигасе, ты прав! Как странно! <img src="https://bank.example.com?function=transfer&amount=1000&toaccount=23234554333&from=checking" />.

Штука в том, чтобы заставить клиентов «Крупного Банка» войти в аккаунт и попытаться сложить цифры счёта. Когда они увидят, что это не работает, они возвращаются на «Популярный Сайт», чтобы снова прочитать пост или оставить гневный комментарий. К сожалению для «идеальной жертвы», её браузер все ещё хранит сеанс входа в онлайн-банк. Когда она попадает на страницу с атакой CSRF, запрос отправляется на веб-сайт банка (где личность жертвы установлена), и вуаля! - жертва лишилась денег.
Изображение в комментарии (со ссылкой CSRF) не будет отображено, и большинство людей будут думать, что это просто плохой аватар или смайлик. Но на самом деле, это удалённый вызов страницы.
Другой вариант: попытаться завлечь пользователя на страницу, внутри которой будет скрытый iframe, выполняющий аналогичный удалённый вызов (в том числе POST).

Предотвращение атак CSRF
1. Проверка токенов
Заключается в проверке того, что пользователь, отправивший данные на ваш сайт, сделал это добровольно. Самый простой способ сделать это – добавить скрытое поле с уникальным значением. Вы можете сделать это с помощью HTML помощника:

@Html.AntiForgeryToken()

Это добавит скрытое поле:

<input type="hidden" value="012837udny31w90hjhf7u" />

То же значение сохраняется в сессии и проверяется в методе обработки формы с помощью фильтра метода действия:

[ValidateAntiforgeryToken]
public ActionResult Register(…)

2. Идемпотентный GET
Вы можете предотвратить целый класс CSRF-атак, ограничив изменения на вашем сайте только запросами POST. Это включает регистрацию, вход/выход из системы и т.п. Подробнее о методах GET и POST.

3. Проверка HttpReferrer
Проверку HttpReferrer также можно реализовать с помощью создания фильтра метода действия:

public class IsPostedFromThisSiteAttribute : AuthorizeAttribute {
 public override void OnAuthorize(AuthorizationContext filterContext) {
  if (filterContext.HttpContext != null) {
    if (filterContext.HttpContext.Request.UrlReferrer == null)
      throw new System.Web.HttpException("Неверная отправка");
    if (filterContext.HttpContext.Request.UrlReferrer.Host != "mysite.com")
      throw new System.Web.HttpException("Форма отправлена не с этого сайта!");
    }
  }
}

Использование:

[IsPostedFromThisSite]
public ActionResult Register(…)

Источник: Jon Galloway “Professional ASP.NET MVC 5”. – John Wiley & Sons Inc., 2014. Глава 7.