Всех приветствую, меня зовут Владислав, я специализируюсь на мобильной безопасности Android‑приложений. На написание данной статьи меня «вдохновила» ситуация, с которой я столкнулся пару недель назад. В целях развития своих навыков и знаний в области ИБ — я активно изучаю чужие приложения с целью поиска уязвимостей (в рамках скоупа и закона, естественно). В связи с этим, хотел бы поразмыслить над темой оценки уязвимостей. 

В мире информационной безопасности есть два понятия, которые часто путают: баг и уязвимость. Баг — это ошибка в коде или логике, которая приводит к неожиданному поведению. Уязвимость — это баг, который можно использовать для нанесения ущерба. Но где проходит граница? Кто решает, что ошибка — это «просто баг», а что — «угроза безопасности»?

Недавно я нашёл баг в одном крупном приложении. Я был уверен, что это — уязвимость. Бизнес ответил: «Нет, это не угроза». Этот случай заставил меня задуматься: а как вообще бизнес принимает такие решения?

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

Баг и уязвимость: в чём разница

Давайте начнём с определений.

Баг — это отклонение от ожидаемого поведения. Кнопка не нажимается, текст съезжает, уведомление приходит с задержкой. Это ошибка, но она не обязательно угрожает безопасности.

Уязвимость — это баг, который может быть использован для атаки. Кража данных, подделка запросов, обход защиты, повышение привилегий. Уязвимость всегда связана с риском: конфиденциальность, целостность, доступность (триада CIA).

Но есть зона неопределенности. Баг, который сегодня кажется безобидным, завтра может стать частью цепочки атаки. Баг, который не затрагивает CIA напрямую, может создавать репутационные риски. Как бизнес это оценивает?

Как бизнес оценивает риски

У бизнеса есть ограниченные ресурсы. Команда безопасности не может чинить всё подряд. Поэтому она приоритезирует.

Основной фильтр — CIA:

  • Конфиденциальность. Может ли кто‑то получить доступ к чужим данным?

  • Целостность. Может ли кто‑то изменить чужие данные?

  • Доступность. Может ли кто‑то нарушить работу сервиса?

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

Мой случай: иллюстрация серой зоны

Теперь — пример из моего опыта. В одном Android-приложении я обнаружил, что защитный механизм ограничения действий при использовании VPN работает некорректно. Отправка текста блокируется, а отправка файлов — нет.

Естественно, после нахождения данной уязвимости я оформил отчёт. Аргументация моей находки была трактована следующим образом: 

  1. Защитный механизм есть, но он не работает.

    В приложении реализован осознанный защитный механизм: ограничение действий при использовании VPN. Это не случайная особенность, а спроектированное решение. Если механизм работает некорректно, значит, он не выполняет свою функцию. Сам факт его существования означает, что бизнес считает VPN‑активность фактором риска. А раз фактор риска признан, его обход не может быть просто «багом интерфейса».

  2. Сокрытие IP‑адреса — это инструмент атакующего

    VPN — один из базовых инструментов для анонимизации в сети. Если приложение ограничивает действия под VPN, логично предположить, что цель — деанонимизация пользователя. Обход этого ограничения возвращает атакующему возможность действовать скрытно. Это не разовая шалость, а потенциальный канал для систематического злоупотребления: распространения фишинга, вредоносных файлов, спама.

  3. Затруднение расследования

    Без VPN действия пользователя можно отследить по IP. С VPN — нельзя. Особенно, если VPN не сохраняет логи. Если злоумышленник использует эту лазейку для атаки, расследование инцидента усложняется. Это не прямое нарушение CIA, но это реальный операционный риск для команды безопасности.

  4. Прецедент для более серьёзных атак

    Сегодня это файлы. Завтра может оказаться, что проверка VPN не работает ещё и для голосовых сообщений, видеозвонков или других функций. Каждый такой случай — не отдельный баг, а симптом одной проблемы: проверка VPN реализована не как сквозной контроль, а как локальная заплатка в интерфейсе. Это архитектурный недостаток, который может проявиться в других местах.

  5. Репутационные риски

    Представьте, что кто‑то использует эту лазейку для массовой рассылки фишинговых файлов. Пострадавшие пользователи не будут разбираться в тонкостях триады. Они скажут: «Меня атаковали через ваше приложение». Репутационный ущерб сложно измерить заранее, но он реален. И он наступает не в момент обнаружения бага, а в момент его публичной эксплуатации.

Интересный вопрос. Что же ответили мне команда безопасности? Цитирую: «Поведение не затрагивает конфиденциальность, целостность или доступность. Описываемое вами поведение не является уязвимостью.». Статус: «Информативный».

И вроде бы как формально они правы. Я не получил доступ к чужим данным. Я не внес в них изменения. Я не нарушил работу сервиса. По критериям CIA это действительно не уязвимость.

VPN‑контроль, скорее всего, внедрён не для реальной защиты от хакеров, а для политики безопасности или ограничения ботов. Его обход не грозит прямыми убытками. Поэтому бизнес не считает это приоритетным.

Но почему я считаю, что это важно?

Потому что безопасность — это не только CIA. Если защитный механизм существует, он должен работать. Если его можно обойти, это прецедент. 

Кроме того, репутационный ущерб сложно измерить в терминах CIA. Если кто‑то начнёт массово рассылать фишинг через приложение, используя эту лазейку, последствия будут реальными. Но их сложно предсказать заранее.

Какие выводы были сделаны? Этот случай научил меня нескольким вещам.

Баг ≠ уязвимость. Не каждая ошибка в коде является угрозой безопасности. Бизнес оценивает риски по своим критериям, и они не всегда совпадают с тем, что видит безопасник.

CIA — это основа, но не всё. Формальные критерии — хороший фильтр, но они не покрывают все риски. 

Безопасник должен говорить на языке бизнеса. Чтобы твой отчёт приняли, недостаточно описать техническую дыру. Нужно показать, как она влияет на деньги и репутацию.

А как вы определяете границу между багом и уязвимостью?