Security by obscurity в мобильных приложениях: почему этот принцип неправильно понимают

Принцип security by obscurity знаком каждому, кто хоть немного погружен в кибербезопасность. В дословном переводе это «безопасность через неясность», и у него устойчиво негативная репутация. Считается, что нельзя строить защиту, полагаясь только на то, что атакующему неизвестно внутреннее устройство системы. Например, в криптографии безопасность не строится на сокрытии алгоритма: атакующий может знать, как устроено шифрование, но не знает закрытого ключа — именно это делает систему устойчивой. Логика понятна и, на первый взгляд, не вызывает вопросов.

Но если посмотреть на практику, возникает противоречие. Закрытый исходный код, фаерволы, защита от реверс-инжиниринга — все это в той или иной степени усложняет понимание системы извне. Даже в криптографии существует направление white-box cryptography, где ключ хранится прямо в коде, а реализация строится так, чтобы максимально затруднить его извлечение. Возникает закономерный вопрос: если «безопасность через неясность» считается плохой практикой, почему индустрия продолжает использовать инструменты, которые, по сути, работают по этому же принципу? На него в экспертной статье специально для Кибер Медиа ответит руководитель разработки PT MAZE Николай Анисеня.

Пример: мобильное приложение банка

Чтобы разобраться, удобно рассмотреть конкретный пример — мобильное банковское приложение. Как его защищать? Один из очевидных ответов — использовать протектор: обфускацию кода, шифрование, проверки окружения (root/jailbreak), защиту от отладки.

На это часто возражают: «Но это же и есть security by obscurity». И формально это действительно так. Но только если рассматривать такие меры в отрыве от остальной системы защиты. Если в приложении не продумана архитектура, если критичная логика не вынесена на сервер, если уязвимости не исправляются — рано или поздно любое приложение разберут. В этом случае никакая обфускация не спасет.

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

Но идеальный мир — редкость

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

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

Защита от реверса — тот же слой, что и фаервол

Вернемся к примеру с банком. Нужно ли ставить фаервол? Очевидно, да. Но фаервол не устраняет уязвимости — он лишь усложняет атаку. Это дополнительный слой защиты.

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

Где возникает путаница

Проблема в том, что security by obscurity часто трактуют неправильно. Ключевой момент звучит просто: «Неясность — это это зыбкий фундамент, когда она используется вместо других мер защиты, а не вместе с ними».

Если защита строится только на сокрытии — это плохая практика. Если же сокрытие используется как дополнительный слой — это нормальный и рабочий подход.

Экономика атаки

Поиск уязвимостей для атакующего — это всегда своего рода лотерея. Он не знает заранее, найдет ли точку входа. Но он точно оценивает стоимость этой попытки.

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

На практике речь идет не о процентах, а о порядках: защищенное приложение может быть в десятки и даже сотни раз дороже в анализе по сравнению с незащищенным. Базовые техники увеличивают стоимость атаки кратно, а комбинация с продвинутыми механизмами — уже на порядок.

В результате:

• растут затраты времени
• требуется более высокая экспертиза
• увеличиваются прямые расходы

И в какой-то момент атака просто перестает быть целесообразной. Гораздо проще выбрать менее защищенную цель.

Именно поэтому такие меры работают: они не делают систему «невзламываемой», но меняют экономику атаки.

С чего начинать защиту

Здесь возникает практический вопрос: что делать в первую очередь, особенно если ресурсы ограничены?

Популярная концепция в безопасности — shift left, то есть работа с уязвимостями на ранних этапах разработки. Но на практике начинать имеет смысл с противоположной стороны — с той, которая ближе всего к атакующему.

Хорошая аналогия: если вы хотите поставить сигнализацию и видеонаблюдение, сначала стоит просто повесить замок на дверь.

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

Практика: что еще важно

При этом важно понимать, что защита от реверса — это не единственный элемент системы.

В базовом варианте для приложения можно выделить несколько обязательных шагов:

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

Ограничения и здравый смысл

Ни один из методов защиты, включая white-box криптографию или обфускацию, не дает 100% гарантии. Их задача — не «закрыть систему навсегда», а усложнить атаку.

То же самое касается и других решений: важно не столько выбрать одну «идеальную» технологию, сколько правильно комбинировать защитные механизмы.

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

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

Это означает, что анализ слабозащищенных приложений станет еще дешевле и быстрее. А значит, разрыв между защищенными и незащищенными системами будет только расти.

Security by obscurity — не «плохой принцип» сам по себе. Проблема возникает только тогда, когда его используют как единственную линию защиты. В реальной системе безопасности он может и должен работать как дополнительный слой, который усложняет жизнь атакующему.

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