😈 Подделка запросов (CSRF, XSRF, SSRF)

Автор cryptoparty На чтение 4 мин Опубликовано 07.11.2023

В 2020 году компания CheckPoint Research сообщила о многочисленных уязвимостях в популярном приложении для социальных сетей TikTok.

Одна из найденных уязвимостей позволяла злоумышленнику удалить видео другого пользователя, создать видео от его имени, автоматически стать его подписчиком или даже изменить приватное видео на публичное.

Именно так – любой желающий мог выполнить эти действия с чужой учетной записью TikTok.

И все это благодаря так называемой межсайтовой подделке запросов (Cross-Site Request Forgery, также известной как XSRF или CSRF).

Содержание

Что такое межсайтовая подделка запросов?
Предотвращение CSRF с помощью токенов
Подделка запросов на стороне сервера (SSRF)
Предотвращение SSRF

Что такое межсайтовая подделка запросов?

CSRF возникает в тех случаях, когда злоумышленник может выполнить действия от имени авторизованного пользователя.

Мы уже говорили о примерах с TikTok, но это также может означать, что злоумышленник может изменить пароль на любой другой, инициировать списание средств, перевод средств, удаление учетных записей и т.д.

В принципе, любое действие, которое может совершить легитимный пользователь со своим аккаунтом, злоумышленник может совершить с помощью CSRF-атаки.

Это можно сделать с помощью простой фишинговой атаки, отправив пользователю письмо со специально созданным URL.

Для примера рассмотрим сценарий из блога компании Imperva.

Злоумышленник может заметить, что конечная точка URL для инициирования передачи данных выглядит следующим образом:

GET http://netbank.com/transfer.do?acct=PersonB&amount=$100 HTTP/1.1

Они могут модифицировать конечную точку так, чтобы она была связана с их учетной записью:

GET http://netbank.com/transfer.do?acct=AttackAccount&amount=$100 HTTP/1.1

Затем они могут отправить эту ссылку непосредственно знакомым, которые пользуются услугами того же банка, или вставить ее в электронное письмо в виде гиперссылки:

<a href="http://netbank.com/transfer.do?acct=AttackAccount&amount=$100">Read more!</a>

Невинная на первый взгляд ссылка оказывается вредоносной, по которой с вашего счета на счет злоумышленника может быть переведено 100 долларов, если сайт банка уязвим для этой атаки.

Предотвращение CSRF с помощью токенов

Широко распространенным средством защиты от атак CSRF являются так называемые CSRF-токены.

Эти маркеры генерируются случайным образом для запросов и проверяются приложением перед обработкой запроса.

Таким образом, если запрос имеет легитимный CSRF-токен, то приложение может его обработать.

Если же CSRF-токен уже недействителен, то приложение может отбросить запрос.

Подделка запросов на стороне сервера (SSRF)

Существует также атака, называемая подделкой запросов со стороны сервера (Server-Side Request Forgery, или SSRF).

Она похожа на CSRF, но имеет ряд ключевых отличий.

Вместо того чтобы выполнять запросы от имени пользователя, SSRF направлена на злоупотребление функциональностью веб-сервера для чтения или модификации внутренних ресурсов, которые не должны быть доступны конечным пользователям.

Или же ресурсы могут быть доступны конечным пользователям, но только с ограниченным доступом.

Однако веб-сервер имеет неограниченный доступ к этому ресурсу, что позволяет обычным пользователям повышать свои привилегии доступа к нему.

Это возможно потому, что злоумышленник может послать запрос на веб-сервер, и тот выполнит его от имени злоумышленника, но при этом может не учесть, что запрос был вредоносным.

POST /vidgif/upload HTTP/1.1 Host: imgur.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Accept: */* Accept-Language: en-US,en;q=0.5 Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With: XMLHttpRequest Referer: http://imgur.com/vidgif/video/between/56.72/9.71?url=http%3A%2F%2Fwww.onirikal.com%2Fvideos%2Fmp4%2Fbattle_games.mp4 Content-Length: 127 Cookie: REDACTED; Connection: close source=http%3A%2F%2F192.166.218.53%2Fmalicious123.php&url=http%3A%2F%2F192.166.218.53%2Fmalicious123.php&start=56.72&stop=66.43

Предотвращение SSRF

Средства защиты, аналогичные тем, о которых мы говорили для веб-уязвимостей, применимы и для SSRF.

Эта уязвимость возникает из-за доверия к вводимым пользователем данным, чего делать ни в коем случае нельзя.

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