Сегодня решили обсудить тему информационной безопасности. Публикуем перевод статьи 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 июля: Проблема решена, составлен отчет.
