Подделка межсайтовых запросов (CSRF)
Атака CSRF вынуждает аутентифицированного пользователя (жертву) отправить поддельный HTTP-запрос, включая cookie сеанса жертвы, в уязвимое веб-приложение, что позволяет злоумышленнику заставить браузер жертвы генерировать запрос, который уязвимое приложение воспринимает как законные запросы от жертва.
Давайте разберемся с агентами угроз, векторами атак, слабостями безопасности, техническим воздействием и последствиями для бизнеса этой уязвимости с помощью простой диаграммы.
пример
Вот классический пример CSRF -
Step 1 - Допустим, уязвимое приложение отправляет запрос на изменение состояния в виде простого текста без какого-либо шифрования.
http://bankx.com/app?action=transferFund&amount=3500&destinationAccount=4673243243Step 2 - Теперь хакер создает запрос, который переводит деньги со счета жертвы на счет злоумышленника, встраивая запрос в образ, который хранится на различных сайтах под контролем злоумышленника -
<img src = "http://bankx.com/app?action=transferFunds&amount=14000&destinationAccount=attackersAcct#"
width = "0" height = "0" />Руки вверх
Step 1- Давайте выполним подделку CSRF, встроив Java-скрипт в изображение. Снимок проблемы приведен ниже.
Step 2 - Теперь нам нужно смоделировать передачу в изображение 1x1 и заставить жертву щелкнуть по нему.
Step 3 - После отправки сообщения оно отображается, как выделено ниже.
Step 4- Теперь, если жертва щелкает следующий URL-адрес, выполняется передача, которую можно обнаружить, перехватывая действия пользователя с помощью пакета burp. Мы можем увидеть перевод, заметив его в сообщении Get, как показано ниже -
Step 5 - Теперь при нажатии кнопки «Обновить» отображается отметка о завершении урока.
Профилактические механизмы
CSRF можно избежать, создав уникальный токен в скрытом поле, который будет отправлен в теле HTTP-запроса, а не в URL-адресе, который более подвержен раскрытию.
Принуждение пользователя к повторной аутентификации или доказательство того, что он является пользователем, для защиты CSRF. Например, CAPTCHA.