Comments 16
Знакомая бага. Лет 8 назад, я такую же у регионального сотового оператора находил. Можно было в личный кабинет одного из сервисов попасть и слить весь баланс. По началу не верили, пришлось у них в офисе демонстрацию проводить, но исправили и даже футболку подарили.
Мне по операторам, например, вот такая статья нравится: https://habr.com/ru/post/305706/, и этот комментарий в моей.
Во втором случае ведь ещё и есть полный доступ к сервису смс-оповещений от имени компании. В запросе и API-ключ присутствует. Так что можно на любые номера отправлять от их имени и за их счёт смс-сообщения.
Про СМС рассылку это классика, надо было разослать клиентам сообщения «Ваши данные скомпрометированы, звоните на горячую линию магазина» и исправят охотнее если им не наплевать.
Есть ещё во многих приложениях привязка банковской карты к аккаунту, советую обратить на это особое внимание. Получив доступ к чужому профилю можно скопировать токен привязанной карты, добавить его в своё приложение и идти покупать товар, либо написать скрипт для оплаты чужой картой.
Есть ещё во многих приложениях привязка банковской карты к аккаунту, советую обратить на это особое внимание. Получив доступ к чужому профилю можно скопировать токен привязанной карты, добавить его в своё приложение и идти покупать товар, либо написать скрипт для оплаты чужой картой.
Собственно, выше я написал, что с помощью этого запроса SMS нельзя было рассылать, но кто знает, что можно в том сервисе рассылок)
А по токенам — да, в конце третьего случая я указал: похоже на токен из моей предыдущей статьи Как ездить на такси за чужой счёт — это как раз оно)
А по токенам — да, в конце третьего случая я указал: похоже на токен из моей предыдущей статьи Как ездить на такси за чужой счёт — это как раз оно)
Странно получается просто, если нельзя менять текст сообщения то как тогда приложение отсылает разные коды? Или оно отсылает одно и тоже сообщение каждый раз? Вы пробовали генерировать sign?
А про второе тупанул, думал речь была о скидочных картах.
А про второе тупанул, думал речь была о скидочных картах.
Скорее всего использовать чужой токен в своем приложении не позволит сервис провайдер или процессинг банка.
Токен будет привязан к идентификатору приложения (мерчанта) и покупателя. Вызов этого токена из другого приложения вернет ошибку.
Также в токенизации часто используют одноразовые токены. Перехваченный токен будет действителен только для одной оплаты и привязывать его куда бессмысленно.
Так что тут приоритетная дырка скорее доступ, чем платежные данные.
Токен будет привязан к идентификатору приложения (мерчанта) и покупателя. Вызов этого токена из другого приложения вернет ошибку.
Также в токенизации часто используют одноразовые токены. Перехваченный токен будет действителен только для одной оплаты и привязывать его куда бессмысленно.
Так что тут приоритетная дырка скорее доступ, чем платежные данные.
В указанной статье про такси описано, что я успешно заказал и оплатил такси с чужим токеном.
Там же указан пример документации одного из провайдеров. К сожалению, токены не привязываются к чему-либо.
Там же указан пример документации одного из провайдеров. К сожалению, токены не привязываются к чему-либо.
Знаю много приложений в которых токен привязывается к ID аккаунта. Ну а бывают такие что просто хранят токен на устройстве и не передают его никуда (привет бургеркинг) так что получив доступ к аккаунту придётся привязывать карту вновь.
Можете посмотреть API популярного в Украине платежного провайдера, там нет информации о привязке к ID аккаунта или ещё чему. Такие дела)
На самом деле есть. Если посмотреть на описание формирования платежа.
Там обязательный параметр merchantAccount. А вот clientAccountId необязательный.
Из чего можно сделать вывод, что сервис провайдер имеет возможность проконтролировать, что выданный токен используется только тем мерчантом, который его получил. А вот наличие контроля пользователя под вопросом.
В описанном случае про такси оплата чужим токеном получилась именно потому, что она проходила в рамках одного мерчанта. А контроля пользователя ни у мерчанта ни у сервис провайдера нет.
Сервис провайдеру на заметку: Привяжи токен к пользователю!
Там обязательный параметр merchantAccount. А вот clientAccountId необязательный.
Из чего можно сделать вывод, что сервис провайдер имеет возможность проконтролировать, что выданный токен используется только тем мерчантом, который его получил. А вот наличие контроля пользователя под вопросом.
В описанном случае про такси оплата чужим токеном получилась именно потому, что она проходила в рамках одного мерчанта. А контроля пользователя ни у мерчанта ни у сервис провайдера нет.
Сервис провайдеру на заметку: Привяжи токен к пользователю!
Коллеги прислали аналогичное: Как не нужно реализовывать смс авторизацию
Sign up to leave a comment.
Уязвимости ритейлеров — три случая, когда OTP можно было получить в запросе