209,62
Рейтинг
Timeweb
VDS, виртуальный хостинг, домены, серверы

Кража персональных данных пользователя (PII) с помощью вызова API напрямую

Блог компании TimewebИнформационная безопасностьТестирование веб-сервисов
Автор оригинала: Kunal pandey
Сегодня решили обсудить тему информационной безопасности. Публикуем перевод статьи Kunal pandey, обнаруживаем уязвимости и работаем на опережение!

Введение


Кража персональных данных (PII) пользователя стала для нас обыденным явлением. Злоумышленники находят множество способов получить персональные данные, например, используя XSS- и IDOR-уязвимости, раскрытие конечных точек API (API endpoint) и другое.

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

Объяснение


В одной из приватных программ на Bug Bounty-платформе HackerOne, куда меня пригласили, было предложено протестировать портал магазина, а именно раздел для работы продавца. Здесь сотрудники магазина могут отправить любому покупателю приглашение «Разместить заказ» (Place order). Чтобы получить необходимую информацию, продавец отправляет этот запрос клиентам по электронной почте или с помощью QR-кода.



Получив ссылку с приглашением для совершения платежа, покупатель переходит по: payment-na.examle.com/0811ebf4-d7d0-ba31–9ce68648a5a9 и заполняет необходимые данные.



При перехвате запроса, в Burp Suite обнаруживается конечная точка API метода POST, которая содержит введенные данные.

Запрос


POST /na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 HTTP/1.1
Host: payments-na.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json;charset=utf-8
X-Cdc-Client: 2.15.45
Content-Length: 125
Origin: https://payments-na.example.com
DNT: 1
Connection: close
Referer: https://payments-na.example.com

{"browser_prefilled":[],"customer_details":{"country":"US"..............},"skipped_fields":[],"user_submitted":true,"action":"continueAddressUnverified"}


Ответ




После заполнения формы, операция завершена. Готово!



Во время метода POST на payments-na.example.com/na/customer/client/v1/session/002420e4-e031–47aa-8d94–6f7c40c248c7 вся информация сохранена, оплата произведена.

Этап эксплуатации


Пользователи или злоумышленники могут обнаружить другой раздел портала, где они могут использовать функцию «Разместить заказ», точно так же, как в методе, описанном выше, и получить следующую ссылку для оплаты: payment-na.examle.com/fa5daba4–5d50– 8f80–9eb1-ebia3ea6d665.



В этом случае, просто заполните форму, перехватите запрос в Burp Suite, получите POST-запрос на payment-na.example.com/na/customer/client/v1/session/xxxx, загрузите сгенерированную конечную точку API и отбросьте другие запросы, чтобы мы не отправляли их.

Полученная конечная точка API: payment-na.example.com/na/customer/client/v1/session/96afd42f-4281–4529–9b8c-3ba70b0f000b.

При дальнейшем тестировании эту конечную точку также можно использовать с помощью метода GET в браузере. Ниже приведен снимок экрана с полученной конечной точкой API:



Как мы видим, информация еще не добавлена, а параметры не указаны.

Теперь получим эту API-ссылку и отправим ее другим пользователям, которые заполнили сведения о своих заказах. Как только жертва нажимает на данную API-ссылку, все персональные данные из предыдущей отправки, которые были сохранены здесь (/na/customer/client/v1/session/002420e4-e031–47aa-8d94–6f7c40c248c7), будут скопированы в указанную конечную точку API: /na/customer/client/v1/session/96afd42f-4281–4529–9b8c-3ba70b0f000b.

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

Со стороны жертвы:



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

Персональные данные жертвы:



Таким образом, злоумышленники могли получить персональные данные любого клиента, просто создав новую конечную точку API сеанса и отправив ее другим пользователям.

Работа над ошибками


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

Это позволило избавиться от возможности повторить описанный выше сценарий — атака с копированием персональных данных пользователя через API.

Ключевые моменты


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

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

Ход событий:


22 июля: Я сообщил об уязвимости команде портала.

23 июля: Отчет был рассмотрен командой, уровень серьезности установлен как средний.

23 июля: Получил вознаграждение 500 долларов.

27 июля: Проблема решена, составлен отчет.
Теги:apisecuritytestingbug bounty
Хабы: Блог компании Timeweb Информационная безопасность Тестирование веб-сервисов
+4
1,3k 15
Комментарии 2

Похожие публикации

Лучшие публикации за сутки

Информация

Дата основания
Местоположение
Россия
Сайт
timeweb.com
Численность
101–200 человек
Дата регистрации

Блог на Хабре