[Перевод] Давайте поговорим о шифровании и IDOR (да, снова IDOR)
Представьте себе систему, предназначенную для защиты конфиденциальных данных пользователей (таких как страховые полисы), только такую, что один неверный шаг превратил ее в открытую книгу. Именно на это я и наткнулся, когда копался в одном сервисе защиты регистрации на мероприятия. То, что начиналось как любопытство к API, переросло в находку, которая может предоставить полный доступ к полису любого пользователя. Вот как это происходило, шаг за шагом, и почему это так важно…
Находка: API с секретом
Все началось с веб-сайта, на котором хранятся пользовательские полисы — думайте о нем как о цифровом сейфе для страховых планов. Во время исследования я обнаружил обращение к API: /api/claims/encrypt? text=EUSP2386411060 с моим страховым полисом (EUSP2386411060). Ответом было зашифрованное значение идентификатора моего полиса, знание которого дает доступ к моему полису. Короче говоря, если ваш страховой полис EUSP2386411061, я могу зашифровать его и получить доступ к вашим данным, поскольку зашифрованное значение используется для доступа к PDF-файлу, содержащему информацию о вашем полисе.
Взлом: пошаговый разбор
Давайте рассмотрим как это работает, если идентификатором вашего полиса является EUSP2386401065.
Шаг 1: Шифрование идентификатора
С помощью простого HTTP GET запроса злоумышленник отправляет идентификатор полиса в конечную точку шифрования. Вот как это выглядит:
GET /api/claims/encrypt?text=EUSP2386401065 HTTP/2
Host: [redacted-]
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:122.0) Gecko/20100101 Firefox/122.0
Accept: application/json, text/plain, /
Ответ? Аккуратная маленькая зашифрованная строка: BnmnNGD6EFL2Eeo85nTHA.
Шаг 2: Доступ к полису
Затем злоумышленник берет эту зашифрованную строку и добавляет ее к адресу: /api/certificates/policies/{encrypted_string_from_step_1} Вот так:
/api/certificates/policies/BnmnNGD6EFL2Eeo85nTHA
Буум! Появляется PDF-файл, отображающий детали вашего полиса EUSP2386401065. ФИО, дата рождения, адреса, но самое главное — дата и вид покупки, которые позволяют злоумышленнику пройти аутентификацию.
Шаг 3: Перехват контроля
Вот где всё становится по-настоящему жутким. Вооружившись идентификатором полиса и датой покупки из PDF, направляемся в портал управления сервисом. Выбираем «Номер полиса» в вариантах входа, вводим EUSP2386401065, затем выбираем «Дата покупки» и вводим дату из добытого полиса. И вот, мы получаем полный доступ — возможность управлять или даже перехватить полис.
Это не единичный случай. Идентификаторы полисов следуют числовой схеме, что означает: теоретически, можно зашифровать любой ID, получить его ключ доступа и повторить этот процесс для каждого пользователя в системе.
Шифрование как слабое звено
Так что же здесь происходит? Система использует один и тот же алгоритм шифрования для каждого идентификатора полиса, а зашифрованный результат служит ключом доступа. Нет никаких дополнительных проверок — ни секретного рукопожатия, ни второго фактора. Если вы сможете угадать или получить идентификатор полиса (а они идут последовательно), вы можете зашифровать его, получить ключ и свободно попасть в хранилище полисов. Это всё равно, что запирать сейф ключом, который хранится на нем.
Риски: почему это важно
Это не просто возможность заглянуть в чей-то страховой полис — это полный доступ. Злоумышленник может просматривать, изменять или даже отменять полисы, и всё это без ведома пользователя. Для сервиса, обслуживающего потенциально тысячи пользователей, это универсальный ключ ко всей базе данных. Личные данные, финансовая информация, планы мероприятий — всё доступно для захвата.
Общая картина
Эта статья не для того, чтобы обвинять какую-либо конкретную компанию (именно поэтому некоторые сведения замаскированы). Это напоминание о том, как мы проектируем и обеспечиваем безопасность систем. Шифрование — мощный инструмент, но когда оно является единственным защитником — к тому же предсказуемым — его недостаточно. Последовательные ID, открытые конечные точки и слабые средства контроля доступа — рецепт беды.
Это напоминание: даже самая незначительная оплошность может превратить крепость в карточный домик. В следующий раз, когда вы доверите сервису свои данные, задайте себе вопрос — что мешает кому-то найти ключ?
Ещё больше познавательного контента в Telegram-канале — Life-Hack — Хакер
