search

XSS vs CSRF

hashtag
В чём разница между XSS и CSRF?

Cross-Site Scripting (XSS) позволяет атакующему выполнять произвольный JavaScript в браузере пользователя-жертвы. Межсайтовая подделка запросов (CSRF) позволяет атакующему побудить пользователя-жертву выполнять действия, которые он не намеревался выполнять. Последствия уязвимостей XSS, как правило, серьёзнее, чем у уязвимостей CSRF:

  • CSRF часто применим только к подмножеству действий, доступных пользователю. Многие приложения в целом реализуют защиты от CSRF, но упускают одну-две операции, которые остаются без защиты. Напротив, успешная эксплуатация XSS обычно может заставить пользователя выполнить любое действие, которое ему доступно, независимо от того, в какой функциональности возникает уязвимость.

  • CSRF можно описать как «однонаправленную» уязвимость: хотя атакующий может побудить жертву отправить HTTP-запрос, он не может получить ответ на этот запрос. Напротив, XSS — «двунаправленная», поскольку внедрённый скрипт атакующего может отправлять произвольные запросы, читать ответы и эксфильтровать данные на внешний домен по выбору атакующего.

hashtag
Могут ли CSRF-токены предотвратить XSS-атаки?

Некоторые XSS-атаки действительно можно предотвратить с помощью эффективного использования CSRF-токенов. Рассмотрим простую Reflected XSS, которую можно тривиально эксплуатировать так:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>

Теперь представим, что уязвимая функция включает CSRF-токен:

https://insecure-website.com/status?csrf-token=CIwNZNlR4XbisJF39I8yWnWX9wX4WFoz&message=<script>/*+Bad+stuff+here...+*/</script>

Предполагая, что сервер корректно валидирует CSRF-токен и отклоняет запросы без валидного токена, токен действительно предотвращает эксплуатацию уязвимости XSS. Подсказка здесь в названии: «Cross-Site Scripting», по крайней мере в своей Reflected Forms, включает Cross-Site запрос. Предотвращая возможность атакующего подделать Cross-Site запрос, приложение предотвращает тривиальную эксплуатацию уязвимости XSS. Здесь возникают важные оговорки:

  • Если Reflected XSS существует где-либо ещё на сайте в функции, не защищённой CSRF-токеном, то такую XSS можно эксплуатировать обычным образом.

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

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

PreviousCross-Site Request Forgery (CSRF)NextКак предотвращать уязвимости CSRF

Last updated