ВХ07. CSRF

Теперь разберем CSRF.

Что такое CSRF?

CSRF - Cross Site Request Forgery, межсайтовая подделка запросов. Это атака, суть которой заключается в том, что от лица жертвы, посетившей контролируемый вами сайт, скрыто осуществляется запрос на другой сервер.

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

Визуализация данной атаки подготовлена нашим подрядчиком, НИИ "КлейДошКроб":

Фокус-группа подтверждает, что как и всегда, всё очень наглядно и понятно.

Но что произойдет, если для перевода денег нужен пароль? Или у вас нет кук от сайта, к которому происходит запрос? (Или у вас нет квартиры, которую можно подарить?) А ничего не произойдет. Запрос будет отправлен в "пустоту".

В CSRF-атаке нет ничего сложного - это совершенно нормальное поведение браузера. Если в html-коде есть какой-то ресурс (картинка, стиль, скрипт), значит надо к нему обратиться.

А вот защита от CSRF требует уже лишних телодвижений. Самое суровое - это на каждый чих требовать отправку пароля. Более адекватное и рабочее - к каждому критичному запросу добавлять CSRF-токен (тут токен - это просто рандомная белиберда из кучи символов).

Например:

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

Какие запросы можно подделать?

GET-запросы. Для CSRF-атаки надо подсунуть пользователю скрипт, где будет что-то из этого:

Для 100% варианта можно и просто редиректнуть пользователя (meta, js, headers).

С GET-запросами всё просто, но по стандартам, которые никто не читает, ни один GET-запрос не должен изменять состояние приложения. Проще говоря, в теории не должно быть возможности дропнуть бд простым GET-запросом. Но на практике всё по другому.

POST-запросы. Для подделки POST-запросов тег img уже не подойдет, надо создавать форму со скрытыми полями и отправлять ее по загрузке страницы:

Немного сложнее скрыто загрузить файл, от имени жертвы:

Как видно из кода, мы шлем XmlHTTPRequest, с произвольными заголовками. Нет смысла каждый раз вручную писать код или переписывать код из шаблона, достаточно воспользоваться BurpSuite. Жмякаем на запросе, который надо подделать и выбираем:

Если что-то непонятно, я подрисовал стрелочки.

HEAD, PUT, DELETE, RANDOM (etc). Все прочие методы, кроме GET и POST, по умолчанию подделать нельзя. Можно, если только разраб/админ, по какой-то неведомой причине, не добавил такой HTTP-заговок в вебсервере:

В таком случае, через XmlHTTPRequest можно использовать любой метод (по аналогии с отправкой файла).

Обход типичных защит.

  • Используя XSS. У вас есть XSS? Отлично, любые проверки бесполезны, просто парсим нужный токен и отправляем вместе с запросом.
  • Проверка HTTP-метода. Если запрос отправляется с помощью POST, то меняем метод на GET и наоборот. Может оказаться так, что токен проверяется только в одном из http-методов.
  • Проверка реферера. Самое простое - это сделать запрос без реферера:

    Если этот способ не работает, то можно сделать поддомен, в котором будет адрес сайта на котором мы хотим провести свой запрос:

    Вариант попроще, но с тем же смыслом, это добавить у себя в коде:

    Если код, который чекает реферер кривой, то запрос пройдет. Прочие методы обхода реферера подразумевают манипуляцию с заголовками, а для этого должна быть еще одна уязвимость (CRFL-injection, например).
  • Проверка наличия токена. В некоторых случаях токен проверяется только в том случае, если он есть. Если его нет - не проверяется. Просто убираем параметр с ним из своего кода. Может быть и наоборот - проверяется просто наличие параметра с токеном, а его значение никак не проверяется. Безопасность на уровне "вахтер общежития".
  • Токен не привязан к сессии пользователя. Мы можем сохранить токен и попробовать отправить его с запросом от другого пользователя (например, спарсили запрос в обычной сессии браузера, отправили в режиме инкогнито). Если запрос прошел успешно, то это значит, что мы можем подставлять валидные токены непосредственно перед выдачей их жертве. Можно автоматизировать, можно сделать руками.
  • CAPTCHA. Аналогично методу выше, если капча не зависит от сессии пользователя, можно решить ее заранее и отправить ответ вместе с запросом.

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

Как использовать CSRF?

Помимо использования по назначению, есть некоторые дополнительные опции:

Добавить в отчет. Особенно CSRF-logout. Если у вас был заказ, а в процессе похекинга ничего не нашлось, то надо обильно описывать множественные CSRF, смакуя все незначительные подробности, со вздохами, причитаниями и закатыванием глаз в потолок. Может и не стоило бы об этом писать, но мне достоверно известен случай, когда товарищ получил за подобную писанину 20к $.

А потому, кто знает, может и вам повезет?

Деанон. Если вы нашли CSRF на каком-то крупном ресурсе, и вас есть, например, возможность скрыто добавить лайк/плюсик, то можно написать скрипт, который парсит тех, кто сделал недавно определенное действие (или посетил одну из страниц).

Cookie Stuffing. Действия следующие:

  1. Регистрируетесь в куче партнерок.
  2. Получаете свои реферальные ссылки.
  3. Создаете сайт, на котором будет описание 100500 партнерок.
  4. Гоните на сайт килотонны трафика (можно даже ифреймом, реальных посетителей может почти не быть).
  5. Каждому посетителю, с помощью CSRF подсовываете свои рефки.
  6. Когда в партнерке попросят показать источники трафика, показываете свой убер-пупер-каталог.
  7. PROFIT!

Т.е. у вас будет примерно такая портянка на сайте:

Которая будет открываться на других сайтах в iframe.

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

В целом, это всё, что стоит знать об CSRF на самом базовом уровне.

Ссылки

  • https://ru.wikipedia.org/wiki/Межсайтовая_подделка_запроса
  • https://en.wikipedia.org/wiki/Cookie_stuffing
  • https://www.cossa.ru/trends/171940/
  • https://2017.zeronights.org/wp-content/uploads/materials/ZN17_MikhailEgorov%20_Neat_tricks_to_bypass_CSRF_protection.pdf