Как находить IDOR, как профессионал

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

Нет контента? Не проблема — 1 Баг

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

Заменив ID на идентификатор другого пользователя, который даже не был приглашен, и отправив запрос с помощью repeater, я получил ответ 204 No Content.

Ответ 204 No Content убедил меня в том, что что-то происходит, поэтому я решил изменить метод запроса на GET и вуаля! Ответ содержит полную информация о пользователе.

Продолжив исследование я нашел еще 3 бага: возможность чтения/записи пользовательских постов и такой же IDOR в функционале подтверждения и членства в группах.  

Кто вообще придает значение ID? — 2 Баг

Этот баг позволил мне получить доступ к PII других пользователей, даже несмотря на то, что ID был хэширован. Извлечение информации об аккаунте происходило напрямую через /api/account, без использования какого-либо ID. И все же я смог получить чувствительную информацию пользователей.  

Ниже представлен скриншот извлечения информации о моем аккаунте через /api/account.

Как видите, получить ID не так-то просто. Я пробовал получить его другими способами. Проверял разные пути, например, /api/user, /api/users.

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

Наконец-то это сработало: /api/users?page=1&size=1.

Когда значение параметра size увеличивается, возвращается информация  о разных пользователях.

Неофициальный администратор — 3 Баг

Эта ошибка позволяла мне создавать, редактировать и удалять посты от имени любого пользователя, просто используя их ID (в моем случае администратора).  

Ниже приведен скриншот, показывающий запрос на создание поста.

При изменении значения параметров authorId и team[0][user][id] на ID другого пользователя (я использовал администратора), пост будет создан от имени этого пользователя с возможностью редактировать и удалять его, как показано ниже.

Контролировать все тикеты — 4 Баг

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

Создание тикета поддержки отправлялось мне и представителю службы поддержки по следующей конечной точке: /redacted/Issue/9085/855f5bb19e7b107f66f3e0edc1e9cf7ff39c0ff4

Очевидно, что хеш 855f5bb19e7b107f66f3e0edc1e9cf7ff39c0ff4 связан с ID 9085. Поэтому изменение ID с 9085 на 9084 напрямую не сработало.

Но давайте посмотрим, как выглядит запрос на комментарий.

Да, отправка комментария и изменение ID с 9085 на 9084 сработало и позволило мне оставлять комментарии в других тикетах.

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

Я также без проблем смог закрывать тикеты и загружать файлы.

Захват аккаунта — 5 Баг

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

Обновление конечной точки профиля имело уязвимость IDOR, которая позволяла мне получать контроль над аккаунтами пользователей, изменяя ID пользователя.

Вот скриншот, показывающий запрос на обновление профиля:

Увидев параметр user_id, я заменил его на ID моего аккаунта и отправил запрос, но это не сработало — вернулось сообщение об ошибке: User not authenticated.

Анализируя запрос, я обнаружил странный заголовок авторизации. Когда я декодировал его, там был ID моего аккаунта: ODUxMjIyODY6ODUxMjIyODY= в 85112286:85112286

Я заменил значение заголовка на ID жертвы: ODUxMjIyODU6ODUxMjIyODU= и бум! Запрос был отправлен успешно.

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

Советы

• Не игнорируйте хэшированные/закодированные ID

• Пробуйте разные методы запросов

• Анализируйте запросы и ответы

• Пробуйте разные эндпоинты — перебирайте их, если возможно.

Ещё больше познавательного контента в Telegram-канале — Life-Hack — Хакер