Тест IDOR на уязвимости просмотра по «скопированной ссылке» в вашем приложении

Как выглядит «просмотр по скопированной ссылке» в реальных приложениях

«Просмотр по скопированной ссылке» — это когда кто‑то может открыть страницу в вашем приложении просто вставив ссылку, хотя ему не положено видеть эту запись. Такое часто встречается для счетов, проектов, тикетов поддержки, общих документов и иногда в админских экранах с кнопкой «Copy link».

Опасность не в самой функции шаринга. Опасность в том, что приложение загружает данные только по тому, что есть в URL (например, ID), без проверки, имеет ли текущий пользователь право их смотреть.

Типичный пример: клиент копирует ссылку на свой счёт и шлёт её своему бухгалтеру. Бухгалтер открывает её, будучи залогиненным под своей учётной записью (или вообще не залогинен), и всё равно видит счёт. Ещё хуже: если URL выглядит как /invoice/1042, замена на /invoice/1043 покажет счёт другого клиента.

Многие команды считают себя в безопасности, потому что ссылка «выглядит случайно» (длинная строка). Но случайность — это не разрешение. Если сервер не проверяет доступ каждый раз, случайно выглядящая ссылка всё равно может привести к утечке через шаринг, пересылку, историю браузера, скриншоты или простое повторное использование старого сообщения.

Пользователи обычно описывают это как «странное» поведение, например:

• «Я кликнул ссылку и увидел чужое имя или электронную почту.»
• «Я могу открыть старую ссылку в приватном окне, и она всё ещё работает.»
• «Мой коллега может видеть мою запись, хотя его не добавляли.»
• «Служба поддержки попросила ссылку, и теперь любой с ней может видеть тикет.»

Это руководство шаг за шагом проведёт вас через простой двухаккаунтный IDOR‑тест, чтобы обнаружить небезопасный прямой доступ к объекту без чтения кода. Вы узнаете, что пробовать, что считать утечкой и как сделать доказательства, которые разработчик сможет быстро исправить.

IDOR без технического жаргона

IDOR — это сокращение от insecure direct object access. Проще говоря: вы меняете ID в ссылке (или запросе) и видите чужие данные. Приложение возвращает реальный объект (проект, счёт, сообщение или файл) в основном по идентификатору, не проверяя, имеет ли текущий пользователь право его просматривать.

Типичная картина: вы открываете страницу, и в URL есть ID элемента. Если вы подменяете этот ID на другой и приложение показывает запись другого человека — это ошибка авторизации.

Ключевое различие простое:

• Аутентификация отвечает: «Вы вошли в систему?»
• Авторизация отвечает: «Можно ли вам получить доступ к этому конкретному объекту?»

Многие приложения правильно проверяют первое и всё ещё проваливают второе. Быть залогиненным лишь доказывает, что вы — пользователь. Это не доказывает, что вы должны видеть каждую запись.

Полезная модель:

• Объект: то, к чему вы пытаетесь получить доступ (документ, заказ, тикет)
• Владелец: пользователь или команда, которой принадлежит объект
• Проверка прав: приложение должно подтверждать, каждый раз, что текущий пользователь имеет доступ к этому объекту

Если эта проверка отсутствует или слишком слабая, поведение «скопировать ссылку» превращается в случайное раскрытие данных.

Где чаще всего прячутся баги IDOR

IDOR не появляется на маркетинговых страницах. Он проявляется в «рабочих» частях приложения, где записи загружаются по ID и есть действия типа скачивания или экспорта.

Страницы, которые загружают одну запись по ID

Они распространены, потому что URL часто привязан ровно к одной записи:

• Счета, квитанции, предложения, отчёты, подписанные PDF
• Проекты, задачи, тикеты, заметки, комментарии
• Профили, страницы биллинга, настройки, админские экраны команды или рабочей области
• Вложения, экспорты, ссылки на скачивание изображений/файлов
• Страницы «Share», которые выглядят публичными, но задуманы приватными

Быстрая проверка: если страница полностью меняется при замене всего одного числа или токена в адресе, возможно, ей слишком доверяют ID.

Фоновые API, которые всё ещё дёргают данные

Многие приложения загружают данные через API фоном. Иногда сам экран защищён, но конечная точка API — нет.

Пример: страница тикета закрыта, но эндпоинт вроде getTicket?id=123 всё ещё возвращает детали тикета любому залогиненному пользователю.

Если вы получили приложение, сгенерированное AI (Lovable, Bolt, v0, Cursor, Replit), будьте особенно внимательны. Контроль доступа часто реализован непоследовательно по разным маршрутам, особенно для скачиваний, экспортов и «побочных» эндпоинтов.

Как безопасно подготовить тест двумя аккаунтами

Вы имитируете то, что может сделать реальный пользователь с общей ссылкой. Действуйте безопасно: обычные пользовательские аккаунты, тестовые данные, раздельные сессии.

1. Создайте два обычных пользователя: Аккаунт A и Аккаунт B. Не давайте никому права администратора или роль «видит всё».
2. Если в приложении есть рабочие области, организации или команды — поместите A и B в разные.
3. Под Аккаунтом A создайте 1–2 явных тестовых элемента, которые вы позже узнаете (например, документ с заголовком «IDOR Test - A» или тестовый счёт на $1). Используйте фейковые данные.
4. Запишите, что должно происходить. Например: «Только владелец может просматривать» против «Любой с ссылкой может просматривать, но не редактировать.»
5. Разделите сессии, чтобы логины не смешивались:

• Аккаунт A в обычном окне браузера
• Аккаунт B в инкогнито/приватном окне или в другом профиле браузера

Пошаговый тест: проверка просмотра по скопированной ссылке

Тест простой: Аккаунт A открывает элемент, затем Аккаунт B пытается открыть ту же самую скопированную ссылку.

1. Залогиньтесь как Аккаунт A и откройте целевой объект (счёт, проект, тикет, документ, ветку сообщений).
2. Скопируйте полный URL из адресной строки. Обратите внимание на то, что выглядит как идентификатор (число, похожая на UUID строка, слаг).
3. В отдельной сессии залогиньтесь как Аккаунт B.
4. Вставьте точную ссылку и загрузите её.
5. Если что‑то загрузилось, попробуйте небольшую вариацию, изменив только идентификатор, и обновите страницу.

После проверки страницы просмотра проделайте те же шаги для «побочных дверей», которые часто протекают сильнее, чем главный экран. Ничего не разрушайте.

• Если есть маршрут редактирования, посмотрите, сможет ли Аккаунт B загрузить форму редактирования.
• Если есть действие скачивания/экспорта (PDF, CSV, вложение), проверьте, вернёт ли оно файл.
• Если страница вообще загружается, обратите внимание, какие дополнительные данные появляются (имена, емейлы, суммы, внутренние заметки).

Если Аккаунт B видит хоть что‑то реальное — даже превью или метаданные — считайте это ошибкой авторизации.

Как читать результаты (и что считается утечкой)

Не ищите только драматический «я вижу всё» сценарий. Во многих реальных случаях утечка даёт чуть‑чуть информации, но этого достаточно.

Что означают разные исходы

Сравните, что может сделать Аккаунт B с тем, что видел Аккаунт A:

• Полный доступ: B видит то же, что и A. Явная утечка.
• Частичные данные: B не может нормально пользоваться страницей, но видит имена, суммы, сообщения, вложения. Всё ещё утечка.
• Только метаданные: B узнаёт о существовании записи (заголовок, владелец, временные метки). Всё ещё утечка.
• Правильный отказ: B стабильно блокируется и никакие приватные данные не появляются.

Ответ «404 Not Found» не всегда безопасен. Если для некоторых ID возвращается 404, а для других — другая ошибка, другая страница или заметная разница во времени ответа, вы можете непреднамеренно раскрывать, какие записи существуют.

Следите за тихими утечками

Некоторые приложения скрывают UI, но всё ещё загружают данные. Страница может выглядеть пустой, но ответ (или скачанный файл) содержит приватную информацию.

Также следите за путаницей с правами: просмотр блокируется, но Аккаунт B всё ещё может редактировать, удалять, скачивать или экспортировать.

Тестируйте и на десктопе, и на мобильных устройствах — мобильные представления иногда обращаются к другим эндпоинтам.

Как зафиксировать доказательства, которые разработчик сможет быстро исправить

Хороший отчёт экономит часы работы.

Соберите:

• Точный использованный URL (полный путь и любой видимый ID)
• Дату/время, среду (производство или staging) и браузер/устройство
• Доказательства из обеих сессий (скриншоты или короткая запись)

Когда делаете скриншоты, включите элемент, который доказывает, под каким аккаунтом вы — профиль, email или имя аккаунта. Иначе вам выдадут «не воспроизводится».

Опишите правило, которое должно было применяться, простыми словами:

• «Аккаунт B должен видеть только свои счета.»
• «Только приглашённые участники проекта могут просматривать этот документ.»
• «Только отправитель и получатель могут читать эту переписку.»

Затем перечислите точно, что было раскрыто (имена, емейлы, адреса, суммы, заметки, вложения). Держите тестовые данные фейковыми и безопасными.

Бычая чек‑лист: 5‑минутный IDOR‑скан

Используйте два обычных аккаунта (без админских прав). Выберите несколько типов объектов, которые должны быть приватными между пользователями.

• Убедитесь, что оба аккаунта имеют одинаковую роль и права.
• Протестируйте как минимум три типа объектов (например: документ, загруженный файл и страница биллинга).
• Для каждого типа проверьте не только «просмотр» (попробуйте загрузку формы редактирования, скачивание/экспорт).
• Сделайте одну «угадываемую» замену (например, /items/104 → /items/105 или замените читаемый слаг).
• Проверьте поведение при отказе: недопустимый ID и неавторизованный доступ должны одинаково безопасно обрабатываться.

Также попробуйте открыть ссылку, будучи разлогиненным, в чистом приватном окне. Приватные страницы не должны показывать контент только из‑за наличия URL.

Частые ошибки при тестировании, которые скрывают баг

Команды часто запускают тест один раз, не видят ничего явного и прекращают проверку. Несколько паттернов регулярно маскируют проблему:

• Тестирование двух аккаунтов в одной и той же рабочей области или организации (часто баг проявляется в кросс‑организации).
• Путаница между настоящими «share links» (преднамеренно общедоступными) и приватными ссылками.
• Уверенность, что длинные ID — безопасны. Если сервер не проверяет права, любой валидный ID достаточен.
• Проверка только того, что показывает UI, а не скачиваний/экспоротов или фоновых данных.
• Остановка после одной страницы. Похожие экраны часто реализованы с разными правилами.

Практический подход: тестируйте страницу детали, эндпоинт скачивания/экспорта и любые связанные представления активности/комментариев для того же объекта.

Простой пример для сравнения с вашим приложением

Представьте клиентский портал, где каждый клиент видит свои счета. В Аккаунте A откройте счёт и нажмите «Copy link».

Переключитесь на Аккаунт B (другой клиент) и вставьте этот же URL.

Если Аккаунт B видит итоги, позиции, имя клиента или может скачать PDF — это уязвимость просмотра по ссылке. Приложение доверяет ссылке (или ID в ней) больше, чем правам залогиненного пользователя.

Что должно происходить: приложение блокирует доступ, если Аккаунт B не имеет права видеть этот счёт. Это может быть экран «доступ запрещён», редирект или запрос на логин. Если продукт поддерживает шаринг, ссылка должна работать только если объект явно расшарен, и шаринг должен быть отзываемым.

При внутреннем отчёте держите его конкретным:

• Влияние: «Любой залогиненный пользователь может увидеть счета других клиентов, вставив скопированную ссылку.»
• Затронутые области: «Страница деталей счёта и скачивание PDF.»
• Воспроизведение: «Войти как A, скопировать ссылку, войти как B, вставить ссылку, наблюдать загрузку данных/PDF.»
• Пример увиденных данных: «Итог счёта $X, имя плательщика, содержимое PDF.»

Как исправить и что делать дальше

Исправление, которое действительно работает

Если двухаккаунтный тест показывает просмотр по ссылке, исправление почти никогда не в UI. Исправление — на сервере: при каждом чтении или изменении записи сервер должен подтверждать, что залогиненный пользователь имеет право доступа к конкретной записи.

Не полагайтесь на скрытые кнопки, клиентские проверки или «неугадываемые» ID. Если пользователь может вставить ссылку, изменить один ID и увидеть чужие данные, значит проверка прав отсутствует или неполная.

Что нужно обеспечить на каждом уязвимом эндпоинте:

• Требовать аутентификацию, если страница не должна быть публичной
• Проверять авторизацию для конкретного объекта (владелец, участник рабочей области, роль)
• По умолчанию отказывать в доступе
• Применять одно и то же правило к чтениям, записям, экспортам и скачиваниям
• Логировать отклонённые попытки, чтобы заметить злоупотребления

Что делать дальше

После внесённых изменений снова запустите тот же двухаккаунтный тест для тех же страниц и скачиваний, которые вы тестировали ранее. Исправление одного маршрута часто оставляет «побочную дверь».

Если приложение было быстро сгенерировано с помощью инструментов вроде Lovable, Bolt, v0, Cursor или Replit, запланируйте дополнительное время. В таких проектах часто несколько маршрутов работают с одними и теми же данными.

Если хотите помощи с подтверждением области поражения и чистым исправлением контроля доступа, FixMyMess (fixmymess.ai) специализируется на диагностике и исправлении AI‑сгенерированных кодовых баз, включая ошибки авторизации, упрочнение безопасности и подготовку к деплою.