В одном из предыдущих статей мы рассказывали о том, что такое SQL-инъекция. В этой решили рассказать про другой тип уязвимостей, а именно - подделку запросов пользователя.
Для начала напомним, что мобильные приложения и веб-сайты чаще всего устроены по типу клиент-серверной архитектуры. Такой тип подразумевает, что есть клиенты (наши с вами браузеры и мобильные телефоны) и есть какой-то центральный сервер, который обрабатывает все запросы от этих клиентов. Первые создают http-запросы, а сервер их обрабатывает и делает те или иные вещи, которые эти запросы подразумевают.
Чтобы сервер мог отличить запросы от одного пользователя и другого, придумали авторизацию. Каждый пользователь должен с первым запросом отправить свой логин и пароль. В ответ сервер вернет некий идентификатор, авторизационную cookie с уникальным значением. И запомнит, какому пользователю с каким значением выдал эту самую cookie.
После этого браузер или мобильное приложение автоматически прикладывают эту cookie ко всем последующим запросам. Так сервер сразу понимает, от имени какого пользователя совершаются действия.
Так как, собственно, подделать запрос? Как сделать так, чтобы сервер получил запрос от пользователя, который тот не совершал? Самый простой ответ - заполучить cookie этого пользователя. Но это, конечно, не всегда просто и злоумышленники придумали другой способ.
Когда мы с вами открываем какой-то сайт, браузер сначала получает “скелет” это сайта, т.е. HTML-код. В нем может быть множество ссылок - на картинки, на css-файлы со стилями, на JS-файлы и так далее. Все они могут располагаться как по тому же домену, так и на каких-то CDN. Браузер должен последовательно запросить все указанные в HTML ссылки прежде чем страница будет считаться загруженной. Все эти запросы также происходят по http-протоколу.
Теперь давайте представим, что мы как-то попали на сайт злоумышленника. Например, перейдя по ссылке из email-а или просто как-то нагуглив его. Не суть важно. Что, если на этом сайте, в HTML-коде будет ссылка на как бы картинку, но на самом деле нет. Ведь пока браузер не сходит по этой ссылке, он не поймет, что там никакой картинке нет. То есть мы можем спровоцировать браузер отправить любой запрос на любой домен, просто прописав соответствующую ссылку в HTML-коде своего сайта. Понимаете, к чему я? :)
Давайте оценим еще раз:
- Чтобы совершить какое-то действие, от имени пользователя нужно создать http-запрос.
- Браузер автоматически прикладывает авторизационную cookie ко всем запросам на домен, для которого эта cookie выставлена.
- Браузер делает все http-запросы по адресам, который указаны в HTML-коде открываемого сайта, даже если ссылка ведет на другой домен.
Эти три факта и помогают подделать запрос. На сайте злоумышленника находится ссылка на тот сайт, который является атакуемым. Что-то вроде такого:
<img src=”www.site.com/action/remove_my_profile” />
Когда пользователь, авторизованный на “хорошем” сайте, попадает на сайт злоумышленника, HTML-код “плохого” сайта провоцирует сделать http-запрос на “хороший” сайт. Причем браузер автоматически прикладывает cookie и сервер хорошего сайта будет думать, что пользователь сделал запрос намеренно. При этом действие может быть любым - от невинного разлогина до перевода денег на счет злоумышленника и так далее.
Защитить сайт от этой атаки довольно просто. Задача же тестировщика - убеждаться, что тестируемый сайт защищен.
Если вам интересно научиться находить CSRF и другие типы уязвимостей на вашем проекте, приходите на наш курс по тестированию безопасности - https://www.learnqa.ru/security
Спасибо за внимание.