Фаззинг + IDOR = Права администратора

Эта статья носит исключительно образовательный характер. Автор не несет ответственности за любые последствия ее прочтения.

Данная статья является переводом и ведется со слов автора. Оригинал тут.

Мы будем называть сайт жертвы как example.com. У этой цели есть 6 четко определенных ролей пользователей. Пользователя с низкими привилегиями назовем«Low Privilege», а пользовaтеля с более высокими привилегиями - «Super Admin».

Шаг 01

Мне нравится фаззинг, поэтому в первую очередь я начал с фаззинга для конечной точки «/api/FUZZ» без входа в приложение, используя инструмент ffuf:

Я нашел 4 конечных точки, 2 из них здесь важны:

user/users

user/updateuser

Шаг 02

Я делаю запрос к найденной конечной точке и вижу, что сервер принимает только метод POST:

Шаг 03

Я меняю метод на POST :

И я вижу , что отображается сообщение об отсутствии авторизации для взаимодействия с ресурсом (конечной точкой):

Шаг 04

На этом этапе мне нужен токен авторизации . Чтобы получить его, я вхожу в приложение со своей «Low Privilege» учетной записью:

Я выполняю произвольный запрос и перехватываю его. Запрос содержит заголовок «Authorization» вместе с JWT токеном:

Шаг 05

В конечной точке «/api/vehicle/getLoggedInUserBookings» я вижу заголовок «Authorization: Bearer [token]»:

Шаг 06

Теперь я копирую и вставляю этот заголовок в свой запрос с шага 03. Я добавляю заголовок «Authorization» вместе с токеном, который захватил ранее, и делаю запрос. В этот момент я заметил новое сообщение об ошибке, возвращаемое приложением:

Шаг 07

Теперь первое, о чем я думаю, - это «сбалансировать» запрос, чтобы получить чистый ответ от сервера. Это заставило меня задуматься об изменении некоторых заголовков, таких как «Content Type» и «Accept». Кроме того, я всегда добавляю в запрос случайный параметр (формат JSON) со случайным значением, чтобы определить реакцию сервера:

Шаг 08

Моя первая мысль, когда я столкнулся с новым API, - сохранить каждый параметр, с которым я сталкиваюсь на своем пути. Продолжая эту мысль, я использую параметры, найденные в запросе на шаге 05, для отладки ответов и пытаюсь получить ответ HTTP 200 OK:

Сообщение «User details fetch successfully» говорит мне, что все в порядке!

Шаг 09

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

Итак, я снова использую фаззинг и нахожу верный параметр. Этот параметр был найден с именем «role: 1» :

Правильный синтаксис, чтобы получить верный результат с ffuf выглядит следующим образом :

ffuf -w g0ld3n-api.txt -u https://vulnerable.com/api/endpoint -X POST --data '{"param1":value1,"param2":value2,"FUZZ":6}' -H 'Authorization: Bearer JWT'

Шаг 10.

Затем я отправляю запрос с этим новым параметром (role), и сервер возвращает мне конфиденциальную информацию обо всех пользователях с «ролью», равной «6», соответствующей роли с низким уровнем привилегий:

Шаг 11

На этом этапе я понимаю, что API уязвим к IDOR в своей функциональности для просмотра информации о пользователях. Теперь, проверим, будет ли это так же и для конечной точки «update user», обнаруженной ранее на шаге 01?

Я использую параметры, найденные на шаге 10, и начинаю отладку, чтобы найти правильный ответ от сервера для конечной точки «/user/updateuser». Чтобы сделать правильный запрос, я изменил значение параметра «role»: 6 на «role»: 1:

• Role 6 = Low Privilege
• Role 1 = Super Admin

Я снова вхожу в систему под своим пользователем и вижу, что теперь я супер администратор:

Большое спасибо за чтение и сообщите мне, если вы заметите какие-либо ошибки или несоответствия.

На этом все. Спасибо за просмотр!

Подпишись на канал - @shadow_group_tg.