Основы этичного веб-хакинга (перевод)

Cross Site Request Forgery

Описание 
Cross Site Request Forgery, или CSRF, является атакой, которая 
осуществляется в тот момент, когда вредоносный сайт, пись- 
мо, сообщение, приложение или что-либо иное заставляет бра- 
узер пользователя выполнить некоторые действия на другом 
сайте, где этот пользователь уже аутентифицирован. Зачастую 
это происходит без ведома пользователя. 
Вред от CSRF-атаки зависит от сайта, принимающего дей- 
ствие. Вот пример: 
1. Боб входит в свой личный кабинет в банковском онлайн- 
клиенте, выполняет какие-то операции, но не разлоги- 
нивается. 
2. Боб проверяет свою почту и кликает на ссылку, ведущую 
на незнакомый сайт. 
3. Незнакомый сайт делает запрос к онлайн-клиенту банка 
Боба на перевод денег, передавая информацию в cookie 
Боба, сохранившуюся с предыдущей его сессии. 
4. Сайт банка Боба принимает запрос от незнакомого (вре- 
доносного) сайта без использования CSRF-токена и вы- 
полняет перевод. 
Еще более интересна ситуация, когда ссылка на вредоносный 
сайт может содержаться в валидном HTML, благодаря чему Бо- 
бу даже не придется нажимать на ссылку: <img src=”www.malicious_- 
site.com”>. Если устройство Боба (например, браузер) отрису- 
ет это изображение, оно сделает запрос к malicious_site.com и 
потенциально совершит CSRF-атаку.

Теперь, зная об опасностях, которые несут CSRF-атаки, вы 
можете защититься от них множеством способов, самым попу- 
лярным из которых, возможно, является использование CSRF- 
токена, который должен отправляться с любым запросом, ко- 
торый потенциально может изменять данные (например, с 
POST-запросами). Веб-приложение (такое, как онлайн-банк Бо- 
ба) должно будет сгенерировать токен, состоящий из двух ча- 
стей, одну из которых получит Боб, а вторая будет сохранена 
в приложении. 
Когда Боб попытается совершить запрос на перевод денег, 
он должен будет отправить токен, который будет проверен 
банком на валидность при помощи токена, хранящегося в 
приложении. 
Теперь, когда мы знаем о CSRF и CSRF-токенах, Cross Origin 
Resource Sharing (CORS) становится более понятным, хотя воз- 
можно, я просто заметил это по мере исследования новых 
целей. В общем, CORS ограничивает список ресурсов, которые 
могут получать доступ к данным. Другими словами, когда 
CORS используется для защиты сайта, вы можете написать 
Javascript для вызова целевого приложения, прочитать ответ и 
сделать другой вызов, если целевой сайт вам это позволяет. 
Если это кажется непонятным, то попробуйте с помощью 
Javascript сделать вызов к HackerOne.com/activity.json, прочи- 
тать ответ и сделать второй вызов. Вы также увидите важность 
этого и потенциальные способы обхода в примере #3 ниже. 
Наконец, важно заметить (спасибо Джоберту Абме за указа- 
ние на этот момент), что не каждый запрос без CSRF-токена 
является невалидным. Некоторые сайты могут выполнять до- 
полнительные проверки, такие, как сравнение заголовка исхо- 
дящей стороны (хотя это не является гарантией безопасности 
и есть известные случаи обхода). Это поле, которое идентифи- 
цирует адрес страницы, которая ссылается на запрашиваемый 
ресурс. Другими словами, если исходящая сторона (реферер)

выполняет POST-вызов не с того же сайта, который получил 
HTTP-запрос, сайт может не позволить вызову достигнуть 
того же эффекта, что достигается с использованием CSRF- 
токена. Кроме того, не каждый сайт использует терми csrf при 
создании или определении токена.