Здравствуйте, дорогие друзья.

Подделка запросов на сайте — довольно старая уязвимость, о которой большинство людей не знают. Аналогично подделке запросов на сайте (CSRF) с помощью OSRF злоумышленник может заставить пользователя задействовать веб-браузер для выполнения запросов от имени злоумышленников. Единственное отличие заключается в том, что запрос инициируется из целевого приложения, тогда как CSRF инициируется с сайта, контролируемого злоумышленником.

OSRF

При просмотре OSRF может показаться, что он очень похож на XSS. Это связано с тем, что основной причиной данной уязвимости является использование пользовательских данных для выполнения HTTP-запросов. Пример уязвимого приложения можно найти ниже:

Основная цель этого уязвимого приложения — заставить пользователя отправить запрос на конечную точку “/admin/add”. Это приведет к тому, что приложение добавит пользователя с правами администратора, которого злоумышленник может использовать для входа в приложение жертвы.

Если вы видите XSS в строке 8, вы абсолютно правы, но для целей упражнения давайте предположим, что вводимые пользователем данные обработаны, и мы не можем выйти за рамки единого поля. В этом случае XSS не будет работать, но OSRF будет работать. Помните, что цель состоит в том, чтобы заставить браузер пользователя отправить запрос на “127.0.0.1/admin/add?username=Mikhail&password=Timcore”.. Это создаст нового пользователя-администратора с именем “Mikhail” и паролем “Timcore”. Более подробно рассмотрим конечную точку “/” и то, как “vuln_param” используется для создания атрибута src тега image. Что, если злоумышленник введет “../../”?

Как вы можете видеть выше, это привело к тому, что приложение отправило запрос GET по пути “/” вместо “/images”. Это связано с тем, что символы “../” указывают серверу вернуться к одному каталогу, если вы знакомы с Linux, вы, вероятно, уже знаете об этом.

Приведенный выше запрос немного лучше, если вы посмотрите в правом нижнем углу изображения, вы увидите, что браузер запрашивает “/admin/add.jpg”. Если мы добавим параметры имени пользователя и пароля, мы сможем добавить учетную запись администратора, как показано ниже.:

Обратите внимание, что при отправке нескольких параметров мы должны использовать в URL-адресе символ “&”, иначе браузер подумает, что он относится к первому запросу, а не ко второму. Также обратите внимание, что пароль — “lulz.jpg”, а не “lulz”. Это связано с тем, что к строке в конце добавляется “.jpg”. Чтобы избавиться от этих символов в нашем пароле, мы можем просто добавить фиктивный параметр, как показано ниже:

● http://127.0.0.1:5000/?vuln_param=../../admin/add?username=ghost%26password=lulz %%26 dummy_param=

Наконец, мы можем отправить запрос к конечной точке “/admin/add”, в результате чего приложение добавит нового пользователя с именем “Mikhail” и паролем “Timcore”. Обратите внимание, что, поскольку это сообщение поступает из браузера пользователя, оно будет содержать все файлы cookie для аутентификации пользователей, исходный заголовок приложения и многое другое в зависимости от способа отправки запроса.

Резюме

Если вы можете контролировать часть URL-адреса, используемого для отправки HTTP-запроса, у вас, вероятно, есть OSRF. Для подтверждения попробуйте ввести символы “../”, которые вызовут запрос на поднимитесь по одному каталогу, если это возможно, у вас определенно есть OSRF, вам просто нужно найти интересующую вас конечную точку для вызова. Это довольно старая ошибка, о существовании которой большинство людей не подозревает, и, кроме того, эту уязвимость действительно легко внедрить в ваше приложение. Это в сочетании с тем фактом, что ее легко использовать, делает данную уязвимость довольно опасной.

На этом все. Всем хорошего дня!

Цикл статей по Bug Bounty.