Давайте поговорим о шифровании и 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 - Хакер

Источник: https://habr.com/ru/articles/891478/


Интересные статьи

Интересные статьи

Когда клиент откладывает покупку, ожидая скидки, важно не потерять его интерес. Уведомления о снижении цен на избранные товары помогают вовремя сообщать пользователям о выгодных предложениях, возвраща...
Движок, он же фреймворк (framework), 1С-Битрикс довольно популярен в странах СНГ.Подкупает он своей универсальностью, собственным маркетплейсом со множеством модулей расширения, как платных так и бесп...
Всем привет! Меня зовут Илья, я разработчик в Битрикс24. В последнее время наша команда стремится быть прозрачнее и делиться изменениями в продукте. Мы хотим, чтобы разработчики, использующие Битрикс2...
Почему никому и никогда не удастся скопировать чужое изделие «в ноль», даже китайцам. И как самим сделать лучше, чем оригинал. Года полтора назад нас слегка закидали на Хабре тапками за инструкци...
Привет всем! Меня зовут Михаил, я старший Frontend-разработчик в НЛМК, занимаюсь разработкой одной из внутренних информационных систем на React + Typescript.Расскажу про самый короткий и наименее труд...