Softline объяснила, почему протекторов недостаточно для защиты Android
Изображение: Rami Al-zayat (unsplash)
Большие языковые модели (LLM) упрощают анализ и модификацию Android-приложений. Эксперты Softline считают, что компаниям уже недостаточно усложнять клиентский код: критические проверки необходимо переносить на сервер, а протекторы дополнять контролем целостности, аттестацией и поведенческим анализом.
Как LLM меняют атаки на Android?
Для модификации приложения нужно декомпилировать APK-файл, изучить smali-код, внести изменения и собрать рабочую версию. LLM могут автоматизировать часть этих операций: анализировать код, предлагать правки, находить причины ошибок и помогать при повторной сборке.
Это не делает атаку полностью автономной, но снижает требования к квалификации злоумышленника и сокращает объем ручной работы. По оценке Softline, основной риск связан с тем, что модифицированный клиент может использоваться для обхода локальных ограничений, перехвата данных и вмешательства в бизнес-логику.
Где риск выше?
Наиболее уязвимы приложения, связанные с деньгами, персональными данными и доступом к инфраструктуре.
В финансовых сервисах изменение клиента может использоваться для подмены параметров операций или обхода ограничений. В ритейле и электронной коммерции риски затрагивают платежи, бонусы и учетные записи. Для телеком-компаний актуален доступ к аккаунтам и услугам, для транспорта и логистики: управление заказами и доставкой.
Корпоративные приложения, VPN-клиенты и B2B-сервисы могут предоставлять доступ к внутренним ресурсам. В Softline отмечают, что уровень риска определяет не отрасль, а объем доверия к клиенту. Чем больше решений приложение принимает самостоятельно, тем опаснее модификация кода.
Почему протектора недостаточно?
Обфускация, шифрование, защита от отладки и RASP усложняют анализ приложения и повышают стоимость атаки. Однако они не должны быть единственным уровнем защиты.
LLM могут помогать при повторном анализе и исправлении ошибок. Поэтому протекторы следует рассматривать как способ замедлить атаку, а не как непреодолимый барьер.
«Большие языковые модели снижают порог входа в анализ и модификацию мобильных приложений. Мы рекомендуем исходить из того, что клиентская часть может быть изменена. Критические проверки нужно переносить на сервер, а защиту кода дополнять аттестацией приложения и устройства, поведенческим анализом, антифродом и регулярным тестированием в CI/CD», – Кирилл Лёвкин, проджект-менеджер Softline (MD Audit).
Что проверить в первую очередь?
Специалисты Softline рекомендуют:
- Перенести критическую логику на сервер. Балансы, транзакции, права доступа и лимиты не должны определяться мобильным клиентом.
- Проверять целостность приложения. Подпись кода и контроль изменений APK помогают выявлять модифицированные сборки.
- Использовать аттестацию. Серверная проверка приложения и устройства позволяет учитывать состояние среды выполнения.
- Контролировать поведение. Антифрод, антибот-защита и ограничение частоты запросов помогают выявлять автоматизированные действия.
- Встроить проверки в CI/CD. Сканирование и тестирование устойчивости к модификации необходимо проводить до релиза и после значимых изменений.
Также важно использовать защищенное хранение токенов и ключей, минимизировать присутствие чувствительных данных в памяти и не размещать секреты в коде.
Как строить защиту?
Мобильный клиент следует считать потенциально недоверенной средой. Даже если приложение прошло проверку целостности, сервер должен самостоятельно подтверждать права пользователя, параметры операции и допустимость действия.
Softline помогает компаниям определить, какие функции нужно перенести на сервер, какие средства защиты применить и как встроить проверки в процесс разработки. Такой подход объединяет протекторы, аттестацию, антифрод и серверный контроль.
Развитие LLM не отменяет существующие средства мобильной безопасности, но повышает требования к архитектуре. Задача Softline в таких проектах: выстроить защиту, при которой изменение клиентского кода не дает доступа к критическим операциям.
