В марте 2026 многие обсуждали ситуацию с доступом к изображениям из ЛС мессенджера MAX по ссылкам, сохранённым через Wayback Machine. Тогда же многих не устроил ответ компании:
В телеграм‑каналах распространяется фейк от пользователя Пикабу о фото в МАХ. Это очередной наброс без подтверждений, который опровергли эксперты по кибербезопасности. Личные фото недоступны никому, кроме владельца.Другие пользователи могут увидеть фото только если владелец добровольно поделится ими или ссылкой на них. Ссылку нельзя подобрать или сгенерировать. Все данные пользователей нацмессенджера, включая фото, надёжно защищены.
К сожалению, ситуация хуже, чем кажется. Т.к. проблемы не видят не только в MAX, но и в других компаниях (столкнулся с этим, оповещая компании о похожих проблемах). В статье я расскажу, почему считаю ситуацию — проблемой для всех: пользователей, компании, багхантеров. И как Wayback Machine + IDOR может превратиться в бомбу замедленного действия для компании.
Более того, эта ситуация — наглядный пример, как отлаженный механизм повышения безопасной разработки (что не найдут внутренние безопасники компании — отловят багхантеры) иногда даёт сбой.
Оглавление
В чём проблема
По сути речь про IDOR. Но, проблема в дополнительных фактах, которые не учитываются в этой истории. Сам по себе IDOR — это возможность получить доступ к чужим данным (подробнее про IDOR на странице OWASP или в статье Как одна цифра в ссылке разрушает бизнес: разбираем уязвимость IDOR). Классическое решение проблемы: проверять, что пользователь действительно имеет права на доступ к запрашиваемому объекту. Но, тут начинается самое главное — разработчики задаются вопросом: откуда у атакующего доступ к прямой ссылке? Если сделать параметр сложно подбираемым — атакующему непросто будет его получить. Правда, OWASP говорит, что параметр может быть получен атакующим из истории логов (если речь про QUERY параметры) или истории браузера (предполагается, что к истории браузера могут получить доступ, например, с помощью вируса). Разработчики иногда делают следующий шаг: ограничивают срок действия ссылки. Звучит, вроде, логично: какой толк от ссылки, если за время перебора (если всё же он удался) ссылка уже не работает? И тут на сцену выходит Wayback Machine (он же WebArchive): https://web.archive.org/
WebArchive может сохранить данные, которые когда‑то были доступны по ссылке. Если ссылка отдавала данные без авторизации — WebArchive это бережно сохранит. Даже если ссылки уже нет — данные (как и сам текст ссылки) сохранены в WebArchive. Что можно найти в WebArchive? Например, вот такое
А вот пример установки нового пароля без проверки авторизации
Ссылка сброса пароля должна быть одноразовой и «жить» короткое время. А оказалась многоразовой и живёт месяцами.
И тут интересен момент: как WebArchive узнаёт об этих ссылках? Любой пользователь сам может указать ссылку, которая будет сохранена.
Интерфейс сохранения страницы по ссылке в WebArchive
Кстати, я пользовался этим фактом при подготовке статьи "Как я зарегистрировал CVE и разозлил вендора"
В статье использовал для сохранения постов в телеграм канале (как оказалось — не зря: за время подготовки статьи часть постов из канала была удалена; заранее сохранённые ссылки на посты в WebArchive оказались весьма кстати).
Но, единственный ли это путь получения ссылки? Нет. В соответствующем разделе сайта и на Википедии рассказано (довольно поверхностно), что есть ещё какие‑то сторонние источники. Что это за источники и о каких данных речь — информации мало.
URL с query параметром также может улетать в Яндекс Метрику и их аналоги. Т.е. речь идёт о доверии к безопасности хранения данных в подобных сервисах (вроде Метрики). И дело не только в потенциальных уязвимостях, дающих читать данные сервиса. Но, и в правах сотрудников, ограничивающих доступ к чтению таких данных. Да, есть способ более безопасно передавать в Метрику данные в виде хеша. Но, я, будучи аппсеком, нередко встречаю передачу в Метрику без хеширования. Часто в Метрику передаётся вообще все URL пользователя во время его сессии. А ведь бывает, что в Метрику улетает GET‑запрос с access токеном.
access токен улетел в WebArchive и Яндекс.Метрику
Токен был рабочим — на момент сохранения ссылки в WebArchive
Расширения для браузера, которые могут красть ссылки. В данном случае даже не важно: попала ссылка из такого расширения в WebArchive. Достаточно того, что ссылка попала к злоумышленнику. Ну, и сами браузеры тоже могут собирать (и передавать разработчикам) достаточно обширные данные (статья раз, статья два)
В случае с IDOR — WebArchive выступает катализатором проблемы: он лишь позволяет быстро находить прямые ссылки и их содержимое.
Помимо WebArchive, есть даже специальная утилита для поиска URL: getallurls (или GAU). На Хабре её тоже упоминали (например, тут).
Рекомендации OWASP по безопасной разработке также указывают на необходимость проверять права доступа, не ограничиваясь сложностью идентификатора ссылки: "Additionally, use complex identifiers as a defense-in-depth measure, but remember that access control is crucial even with these identifiers."
В 2015 году Вконтакте именно так и исправили похожую проблему (см Уязвимость «ВКонтакте» позволяла получить прямые ссылки на приватные фотографии).
Мой опыт взаимодействия с компаниями
Проблема кажется понятной: любая ссылка (даже короткоживущая) — не повод игнорировать проверку прав доступа пользователя к запрашиваемому по ссылке объекту.
Но, как выясняется, далеко не все компании видят здесь проблему.
В прошлом году я несколько раз сообщал различным компаниям о похожих проблемах. В т.ч. через багбаунти платформу. Добавлю, что в случае с багбаунти компании часто хотят предоставленного импакта: доказать проблему на практике, а не в теории. Т.е. написать что‑то вроде «доступ по прямой ссылке, если злоумышленник получит доступ к логам веб сервера — он узнает ссылку» ответ может быть в стиле «когда получишь доступ к логам — тогда и приходи» (это не прямая речь, но, хорошо передаёт смысл). Вот, например, из условий для МКБ:
Не вознаграждаем за маловероятные или теоретические атаки без доказательств возможности их осуществления
Казалось бы: тут WebArchive — весьма кстати: приложи к отчёту ссылки WebArchive с содержимым — и дело в шляпе. Я предоставлял с десяток разных ссылок на WebArchive. Ответы были в стиле: «не уязвимость: ручка истекаемая и, вообще, пользователь — сам себе злой Буратино».
Вот, например, ответ насчёт кейса с Глебом Ярославовичем
Были и другие подобные ответы:
Самое интересное: в одной из ответивших так компаний есть как AppSec, так и AppSec бизнес‑партнёр. В задачи последних входят как раз вопросы безопасности архитектуры. Знаю это, так как собеседовался в эту компанию на эту должность относительно недавно (и спрашивал тимлида о задачах). И, тем не менее: проблема сохраняется даже тогда, когда в штате есть люди, которые занимаются этими вопросами.
Почему из всех возможных вариантов безапелляционно заявляется лишь один: пользователь сам сохранил данные в WebArchive?
Лично я сильно сомневаюсь, что большинство пользователей сами передают данные в сервис.
Во‑первых, минимальное временное различие, которое я видел (между созданием ссылки и сохранением её данных в WebArchive) — несколько секунд.
WebArchive сохранил ссылку спустя 5 секунд
5 секунд — учитывая разницу во времени в 3 часа: в 20:18:01 сформирована операция, в 18:06 ссылка сохранена.
Точность времени самого WebArchive проверял через сервис точного времени https://time.now/developer/api/timezone/Europe/London Т.е. через WebArchive сохранил ответ сервера точного времени — так и узнал время в WebArchive относительно сервера точного времени. Вот снимок ответа точного времени https://web.archive.org/web/20260513100507/https://time.now/developer/api/timezone/Europe/London
Точность времени сайта из URL, сохранённого в WebArchive, проверял сверкой времени в ответе сервера (находил на сайте метод, который показывал операцию — например, формирование отчёта или проведение какой‑то оплаты).
Т.е. пользователю нужно за это время: найти нужную ссылку, передать её в сервис WebArchive. При этом, для заполнения данных в WebArchive через браузер, требуется время (указать url, нажать кнопку save).
Во‑вторых, в тех файлах, где есть ФИО\никнейм инициатора платежа — десятки и даже сотни разных ФИО\никнеймов. Неужели был какой‑то не замеченный обществом флешмоб в стиле: «сохрани платёжный документ со своими ФИО в сервисе WebArchive»? И при этом этот флешмоб всё никак не остановится? Можно ещё понять любопытство пользователя по сохранению ссылки на pdf‑файл (его и получить из браузера легче). Но, зачем пользователям массово искать и сохранять ссылки на json?
Исходя из анализа различных URL на WebArchive, у меня складывается ощущение, что причины попадания ссылок в WebArchive различны. Но, часть ссылок утекает ровно в тот момент, когда пользователь обращается к URL. Варианты: плагины к браузерам, сами браузеры или зловред на устройстве пользователя. В целом, вопрос попадания ссылок в WebArchive (и иные подобные сервисы) — до конца мне не ясен. И был бы рад узнать подробности (если кто‑то ими обладает — напишите в комментариях, пожалуйста).
Да, если утечка URL произошла из‑за вируса на стороне пользователя — угроза от вируса намного более серьёзная, чем просто кража URL, которым ещё нужно воспользоваться. Но, попадание URL в сервисы, вроде WebArchive, масштабируют проблему: ведь этим URL смогут воспользоваться большее количество злоумышленников.
Кроме того, анализ времени между созданием ссылки и временем, когда такая ссылка попадает в WebArchive, показывает бесполезность защиты в виде срока жизни ссылки (если речь идёт о сроке жизни в днях\часах, что часто и бывает).
Проблема для багхантера
Я смог обжаловать ответ одной из компаний в рамках багбаунти. Для этого, мне пришлось искать знакомых, у кого есть выходы на безопасников этой компании. После этого, отчёт был пересмотрен: мне назначили выплату в 5 000 ₽ Это не та цена, за которую хочется в будущем тратить время — легче просто пройти мимо, чем тратить время на подобные отчёты. Учитывая время на поиски вариантов оспаривания. Например, у Бизона написано:
В конфликтных ситуациях лучше приводить аргументы, а не давить на эмоции. Можно предложить пересмотреть размер награды. В любом случае не бойтесь обратиться в нашу поддержку к специалистам с независимой экспертизой в сфере ИБ. Мы поможем разобраться, ведь одна из целей площадки BI.ZONE Bug Bounty — построить максимально выгодное для всех взаимодействие. Для этого мы и выступаем арбитром в непростых ситуациях.
На практике — есть нюансы, когда эта помощь не особо работает.
Вот из моей переписки насчёт оспаривания отказа засчитывать отчёт
Говорят, по их опыту с ПД физлицами проще назвать уязвимостью. Но, Глеб Ярославович из Мурманска не стал уязвимостью (пока я через знакомых не нашёл как оспорить).
И это не только моя проблема. Например, на этой странице одной из площадок багбаунти можно увидеть: немало людей, которым выплачивали по 1 000 — 5 000 руб за уязвимость.
Плюс ко всему, в некоторых багбаунти программах есть параметр эффективности (влияет в т.ч. на доступ к приватным багбаунти программам).
Баллы можно потерять за недостоверные отчёты
Например, в Standoff365 штрафуют за спам (подробнее — на их сайте). При этом, что именно является спамом, понять сложно. Где‑то встречаются рекомендации не присылать одно и то же по несколько раз. Однако, бывают ситуации, когда ответа нужно ждать месяцами — и иногда проще повторно отправить более полный отчёт, нежели ждать ответа в изначальном отчёте.
в комментариях к отчёту предоставил дополнительный импакт - ответ пришёл спустя 1,5 месяца
И ответ пришёл аккурат тогда, когда я начал искать через кого просить пересмотреть отчёт. Т.е. если бы не попытка оспорить — моё сообщение осталось бы не отвеченым.
А на некоторые сообщения из переписки — просто нет ответа.
Например, так и не получил ответа, могу ли публиковать все технические подробности (с указанием компании, которая не сочла находку уязвимостью).
Кстати, это не редкая ситуация, когда компания против публикации отчёта, даже если не считает это уязвимостью — об этом упоминалось в статье Bug bounty в РФ: когда вендор молчит, а платформа подыгрывает.
Т.е., продолжать воевать и делать подобные отчёты, доказывая свою правоту — верный путь испортить свою статистику.
Отказ признавать проблему негативно влияет на репутацию багхантера на разных багбаунти площадках. В прошлом году я зарегистрировал CVE, но отчёт не был принят вендором (подробнее писал в статье Как я зарегистрировал CVE и разозлил вендора).
Что негативно повлияло на мою репутацию на HackerOne
Статья Охотники на баги и где они обитают: итоги опроса о багхантинге тоже подтверждает: многие багхантеры сталкиваются либо с низкой оплатой, либо с отсутствием позитивного опыта работы с багбаунти площадками. Но, в той статье — лишь сухая теория. Причины проблем разными багбаунти площадками (даже зарубежными) раскрываются, помимо этой статьи, и в статьях других авторов:
Bug bounty в РФ: когда вендор молчит, а платформа подыгрывает
Bug Bounty Минцифры: как найти критическую уязвимость и получить дырку от бублика в награду
Критикую bug bounty программу Apple и наглядно показываю, почему не стоит туда репортить баги
Проблема для разработчиков
Сейчас самая главная проблема — репутационный ущерб. Из ситуации с доступом к изображениям из ЛС мессенджера MAX по ссылкам, сохранённым через WebArchive можно увидеть: позиция компании «это не бага, а фича» — устраивает далеко не всех пользователей.
Сервисы, вроде WebArchive, вносят и ещё один неприятный штрих в эту картину в виде бомбы замедленного действия. Представьте: 8 лет назад была небезопасная архитектура с IDOR. Спустя время архитектуру поменяли и проблема ушла. Но, WebArchive всё помнит: ссылки уже успели сохраниться. И кто‑то, спустя многие годы, публикует статью с указанием ссылок на WebArchive, где указаны персональные данные и платёжки клиентов. Внимание, вопрос: успокоит ли общественность реакция в стиле: «да это давно было, сервиса уж нет»?
ВебАрхив знает что вы делали прошлым летом было в 2018-м:
Вторая проблема для компаний — пока носит больше теоретический характер. Т.к. IDOR часто приводят к утечкам персональных данных, тут на сцену выходит статья 13.11 КоАП РФ (в лице Роскомнадзора) и иски от пострадавших пользователей. Пока очень мало судебной практики для полноценных выводов. Но, некоторые предварительные выводы можно сделать.
В мае 2025 статью 13.11 КоАП РФ изменили и дополнили. Поменялись штрафы. А также, появились новые условия для штрафов. В т.ч. ввели такую штуку, как «идентификаторы» (и этот термин тоже определили). Согласно пояснительной записке к законопроекту 502104–8, изменения направлены на значительное снижение количества случаев «утечек» персональных данных.
Из пояснительной записки к законопроекту 502104-8
Попав в руки к злоумышленникам, данные могут стать инструментом для спам‑звонков, нежелательных рассылок, шантажа, мошеннических схем и совершения иных, более тяжких преступлений.
С целью стимулирования операторов персональных данных инвестировать в развитие инфраструктуры информационной безопасности и защиту персональных данных своих пользователей законопроектом предлагается дополнить статью 13.11 Ко АП РФ новыми составами административных правонарушений, предусматривающими установление административной ответственности за утечки баз данных, содержащие персональные данные.
Суровые меры административного наказания, предусмотренные законопроектом, станут существенным стимулом для инвестиций операторов персональных данных в информационную безопасность и окажут превентивное воздействие на операторов, несоблюдающих требования законодательства о персональных данных.
Предлагаемые изменения направлены на значительное снижение количества случаев «утечек» персональных данных в Российской Федерации.
Тут так и не раскрыто, зачем потребовалось вводить термин «идентификаторы». Возможно, для штрафа, когда юридически содержимое утечки не дотягивает до понятия «персональные данные». Вот только есть Постановление Конституционного суда № 22-П от 25.05.2021,исходя из которого следует (как я это вижу), что никакого «не дотягивания» до персональных данных нет.
Из Постановления Конституционного суда № 22-П от 25.05.2021
Федеральный закон «О персональных данных», принятый в целях защиты прав и свобод человека и гражданина при обработке его персональных данных, в том числе защиты прав на неприкосновенность частной жизни (статья 2), определяет, что персональными данными является любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных) (пункт 1 статьи 3); не исключены из объема такой информации фамилия, имя и отчество, год и место рождения, адрес, абонентский номер, сведения о профессии гражданина (часть 1 статьи 8).
Юридическая сила решений Конституционного суда
Согласно Закона «О Конституционном Суде Российской Федерации» решения Конституционного Суда обязательны на всей территории Российской Федерации для всех представительных, исполнительных и судебных органов государственной власти, органов местного самоуправления, предприятий, учреждений, организаций, должностных лиц, граждан и их объединений (статья 6). Решение Конституционного Суда Российской Федерации действует непосредственно и не требует подтверждения другими органами и должностными лицами (статья 79)
Протоколы и штрафы по статье 13.11 КоАП РФ за утечку данных в новостях за 2025–2026 год попадаются. Но, пока носят редкий характер. В связи с чем, вряд ли стоит в ближайшее время ожидать, что 13.11 КоАП РФ станет тем рычагом давления на компании, который реально заставит их более ответственно относиться, в т.ч., к истории с IDOR.
Проблема для пользователей
Я уже писал, что добился пересмотра отчёта в багбаунти. Спустя несколько месяцев, я убедился, что софт переделали и в WebArchive больше не попадают новые ссылки. Но, предыдущие ссылки никуда не делись из WebArchive (хотя, их можно удалить, создав запрос). Видимо, компания не сочла нужным удалить данные из WebArchive.
Новых ссылок больше нет в WebArchive. Но, всё ещё можно узнать, где был Глеб Ярославович
В разделе выше (Проблема для разработчиков) я указывал, что встречал ситуацию, когда в WebArchive были персональные данные пользователей в уже не существующем домене компании (попали туда ещё в 2018). Удалять такие данные, наверняка, очень непросто: вряд ли стоит ждать от компании, что она сама будет этим заниматься (без принуждения). Будучи аппсеком, встречаюсь с ситуацией, что со мной даже разработчики спорят, не желая исправлять сервис, в котором есть раскрытие персональных данных. Суть проста: считают, что им виднее, что есть персональные данные, а что нет. Примерно такую же картину встречаю по своим отчётам в багбаунти: там уже триажеры мне рассказывают, что они считают персональными данными (и, конечно же, в каждой компании — свои триажеры со своим уникальным мнением на этот счёт). Ссылаться на законы или позицию Конституционного Суда — бессмысленно.
Если вы пострадали от утечки своих данных и хочется сатисфакции — стоит подумать об обращении в Роскомнадзор (так как это их задача составлять протокол по статье 13.11 КоАП РФ). И, с иском о моральной компенсации, в суд. Но, чем это всё закончится — сложно сказать заранее: судебная практика по этим делам, по сути, толком не сложилась. В новостях 2025–2026 года есть штрафы за утечки. А вот успешных кейсов, когда пострадавшие сами судятся с компаниями из‑за утечек, найти сложно.
Заключение
IDOR + WebArchive — хроническая проблема, которую игнорируют разные компании. Лично я убеждён, что это происходит из‑за недостаточного понимания ситуации. Конечно, «безопасникам», порой, непросто объяснять разработчикам в чём косяк (писал об этом в заметке А зачем покупаете WAF, который можно обойти?). Но, хуже всего, когда в компании есть специальные люди (аппсеки, аппсек бизнес‑партнёры, архитекторы по безопасной разработке — нужное подчеркнуть) и они тоже не считают ситуацию проблемой. Причины тут разные. В т.ч., назначение на должность человека без опыта в безопасности, а только с опытом разработки (писал об этом в заметке). А ещё, в этой ситуации, вижу очередное подтверждение своей позиции: пентестер\аппсек — как разведчик\контрразведчик, как писатель\литературный критик — редко могут одинаково хорошо сочетать эти навыки в одном человеке. Сейчас я работаю аппсеком, но у меня в прошлом — богатый пентестерский опыт. И я замечаю, как по‑разному, на эту ситуацию смотрю я и мои знакомые коллеги аппсеки без опыта пентеста: я вижу хроническую проблему, а коллеги говорят: «да пол интернета так работает — и ничего!».
Решение в виде одноразовых ссылок мне видится неполноценным: невозможно точно сказать, кто первый перейдёт по ссылке: WebArchive или пользователь.
Отказ признавать проблему со стороны разработчиков — классическая проблема (подход «это не бага, а фича»). В статье Как я зарегистрировал CVE и разозлил вендора я рассказывал о похожей ситуации. Но, тогда речь шла о продукте. И, отказ вендора признавать уязвимость, не помешал мне зарегистрировать CVE (вендор неудачно пытался отозвать CVE и даже заподозрил меня и MITRE в финансовой заинтересованности — подробнее в статье).
В случае с IDOR в веб сервисе, ситуация иная: CVE на такое не оформить. Рычаг давления вида «раскрыть информацию публично» утыкается в юридические вопросы: соглашение, которое принимает багхантер, регистрируясь в программе багбаунти. Кроме того, вендоры бывают против публикаций даже тех отчётов, которые они считают невалидными (из моего опыта с игнорированием вопроса о публикации и из статьи другого автора: Bug bounty в РФ: когда вендор молчит, а платформа подыгрывает). Каковы последствия пойти против позиции вендора? Наверное, всё зависит от конкретной ситуации. Например, в статье Как я обнаружил проблемы у ЮМани (Сбербанк) с безопасностью и не получил денег за найденную уязвимость автор столкнулся с удалением его аккаунта на багбаунти площадке после публикации технических деталей на Хабре.
В целом, эта ситуация наглядный показатель, как работающая в теории формула «что не найдут наши безопасники — выявят багхантеры и мы это пофиксим» разбивается о суровую реальность жизни. Как говорил персонаж из «Фауста» Гётте: «суха теория, мой друг, а древо жизни вечно зеленеет».
А начинающим багхантерам стоит знать: найти уязвимость — это не всегда равно получить за неё выплату. Но, всегда равно потраченного времени.
