Mass Assignment через мобильное API
Еще один пример, который доказывает, что очень важно изучать каждый интерфейс в приложении.
Недавно нашел Mass Assignment через мобильное API в дополнительном модуле приложения, которая была доступна только через мобильное приложение.
Mass Assignment приводил к частичному захвату аккаунта.
Рекон
При изучении мобильного приложения, я наткнулся на некий дополнительный модуль в приложении, который подгружался внутри приложения и отличался внешне, а также был другой поддомен.
Предыстория
Регистрация в приложении происходит cс помощью номера телефона и если есть уже зарегистрированный номер, то при регистрации приложение говорит, что такой номер есть и не дает нам зарегистрироваться. Но что важно, почему это частичный захват аккаунта, приложение при обращении к критическим объектам в аккаунте пользователя проверку осуществлял на основе номера. То есть, приложение знает, какой номер изначально имел доступ к этому объекту и если мы пытались сделать IDOR, то нас посылали.
Также мы не можем поменять номер телефона через профиль пользователя, приложение ругается, что номер уже занят.
Эксплуатация
Вернемся к нашему модулю из мобильного приложения, в этом модуле при изначальном открытии давалась возможность указать ФИО, дату рождения и почту. Я ввел, сохранил, смотрю на запрос и вижу в теле запроса такое:
Перешел в основной профиль и вижу, что эта почта применилась и она уже как подтвержденная. И тут становится понятно, что через данный эндпоинт также можно редактировать профиль и данные никак не проверяются. Добавил в тело параметр
Ура, теперь я могу менять на любой номер, который уже зарегистрирован в приложении. Можно дергать объекты, так как приложение смотрит на номер при проверке и он совпадет с легитимным.
#MA #mobile #api
Еще один пример, который доказывает, что очень важно изучать каждый интерфейс в приложении.
Недавно нашел Mass Assignment через мобильное API в дополнительном модуле приложения, которая была доступна только через мобильное приложение.
Mass Assignment приводил к частичному захвату аккаунта.
Рекон
При изучении мобильного приложения, я наткнулся на некий дополнительный модуль в приложении, который подгружался внутри приложения и отличался внешне, а также был другой поддомен.
Предыстория
Регистрация в приложении происходит cс помощью номера телефона и если есть уже зарегистрированный номер, то при регистрации приложение говорит, что такой номер есть и не дает нам зарегистрироваться. Но что важно, почему это частичный захват аккаунта, приложение при обращении к критическим объектам в аккаунте пользователя проверку осуществлял на основе номера. То есть, приложение знает, какой номер изначально имел доступ к этому объекту и если мы пытались сделать IDOR, то нас посылали.
Также мы не можем поменять номер телефона через профиль пользователя, приложение ругается, что номер уже занят.
Эксплуатация
Вернемся к нашему модулю из мобильного приложения, в этом модуле при изначальном открытии давалась возможность указать ФИО, дату рождения и почту. Я ввел, сохранил, смотрю на запрос и вижу в теле запроса такое:
{“name”:””,“surname”:””,“lastname”:””,“birthDate”:””,“emailConfirmed”:”false”,“email”:””}
Внимание цепляет параметр emailConfirmed, быстро меняю на true, вставляю рандомную почту и отправляю запрос. Перешел в основной профиль и вижу, что эта почта применилась и она уже как подтвержденная. И тут становится понятно, что через данный эндпоинт также можно редактировать профиль и данные никак не проверяются. Добавил в тело параметр
“phone”:”79999999999” и отправил запрос. Ура, теперь я могу менять на любой номер, который уже зарегистрирован в приложении. Можно дергать объекты, так как приложение смотрит на номер при проверке и он совпадет с легитимным.
#MA #mobile #api