Оценка устойчивости Android-клиента, mobile API и клиентских защит

1) Цель review

Мы исходим из практической модели угроз: Android-клиент работает на устройстве пользователя и потенциально может быть проанализирован, модифицирован или инструментирован.

Поэтому цель review — не доказать саму возможность вмешательства в клиент, а оценить, насколько текущая архитектура, защитные механизмы и backend-контроли ограничивают бизнес-риски в таком сценарии. Оценка проводится не в формате бинарных вопросов. Для каждой области фиксируются критерии устойчивости, сложность анализа, воспроизводимость сценария, масштабируемость потенциального abuse и бизнес-влияние.

2) Области оценки

1. Раскрываемость APK при статическом анализе. Оценивается объем и практическая ценность информации, доступной из APK без запуска приложения.

Фокус проверки: локализация критичных компонентов: network layer, request signing, pinning, anti-tamper; выявление API surface, конфигураций, feature flags, debug/internal paths; поиск секретов, ключей, signing material и технических артефактов с практическим влиянием.

Результат: понимание, какие сведения можно получить из APK и насколько они упрощают дальнейший анализ API, защитных механизмов и потенциальных abuse-сценариев.

2. Устойчивость к модификации и перепаковке клиента. Оценивается, насколько приложение и связанные backend-контроли устойчивы к сценарию использования измененной или перепакованной версии клиента.

Фокус проверки: сложность модификации и повторной сборки APK; эффективность проверок целостности и подписи приложения; сохранение доступа к критичным сценариям после изменения клиента; обнаруживаемость модифицированного клиента на стороне backend/antifraud.

Результат: понимание, насколько измененный клиент может быть использован для обхода ограничений, нестандартного взаимодействия с API или подготовки abuse-сценариев.

3. Устойчивость к динамической инструментализации. Оценивается, насколько сложно изменить поведение приложения во время выполнения без пересборки APK.

Фокус проверки: устойчивость к runtime instrumentation; сложность динамической подмены поведения приложения; эффективность anti-debug / anti-hook / anti-emulator механизмов; защищенность критичных клиентских проверок от runtime bypass.

Результат: понимание, насколько динамический анализ и runtime-инструментирование позволяют исследовать, обходить или изменять критичное поведение приложения во время выполнения.

4. Наблюдаемость и читаемость mobile API. Оценивается сложность получения и анализа сетевого взаимодействия Android-клиента с backend API.

Фокус проверки: сложность получения наблюдаемости над API-трафиком; эффективность certificate pinning и TLS-защит; читаемость структуры API, параметров и моделей данных; понятность последовательности пользовательских сценариев по трафику.

Результат: понимание, насколько быстро внешний исследователь может восстановить API-логику и подготовить дальнейшие проверки.

5. Воспроизводимость API и устойчивость к abuse. Оценивается, насколько сложно повторить, модифицировать или автоматизировать API-вызовы вне штатного клиента.

Фокус проверки: сложность воспроизведения API-запросов вне приложения; устойчивость request signing к восстановлению; защита от replay, parameter tampering и нестандартных последовательностей; стоимость автоматизации пользовательских или платежных сценариев; масштабируемость потенциального abuse-сценария.

Результат: понимание, насколько mobile API устойчив к использованию нестандартным клиентом или автоматизированным инструментом.

6. Доверие к клиентской бизнес-логике и компенсирующие контроли. Оценивается, какие пользовательские, платежные и партнерские сценарии остаются корректно защищенными при предположении, что Android-клиент контролируется атакующим.

Фокус проверки: степень зависимости бизнес-логики от состояния клиента; устойчивость критичных сценариев к изменению клиентского состояния; полнота server-side enforcement для операций; защищенность последовательности действий от нестандартного выполнения; влияние client-side bypass на бизнес-сценарии.

Результат: понимание, где критичная логика защищена backend-контролями, а где клиентская сторона создает риск обхода.

3) Модель оценки

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

• Resilience Score: оценка устойчивости механизма: 1/5 — защита отсутствует, 5/5 — многоуровневая защита, высокая стоимость обхода.
• Attack Effort: практическая сложность сценария: навыки, инструменты, время, ручной анализ, стабильность результата.
• Abuse Scalability: возможность превращения сценария в массовое или автоматизированное злоупотребление.
• Business Impact: влияние на продукт, пользователей, платежные сценарии, API abuse, fraud, данные и операционные риски.

4) Пример результата

Пример строки результата

Область: Воспроизводимость API и устойчивость к abuse

Resilience: 2/5 | Attack Effort: Medium | Abuse Scalability: Medium | Business Impact: High

Пояснение: Pinning обходится типовым runtime hook, алгоритм подписи расположен в Java/Kotlin-слое и восстанавливается через статический и динамический анализ. Требуется ручная работа, барьер умеренный. Масштабируемость зависит от доступных операций API и backend-контролей.

Пример результата проверки: воспроизводимость mobile API. Наблюдение: certificate pinning присутствует, обходится типовым runtime hook, проверка завязана на стандартную точку TLS-валидации. Pinning практически не повышает стоимость анализа трафика. Алгоритм формирования подписи в Java/Kotlin-слое может быть восстановлен через декомпиляцию и Smali-анализ.

Бизнес-влияние: основной риск — снижение стоимости анализа mobile API и упрощение разработки нестандартного клиента или автоматизации действий.

Рекомендации: Certificate pinning — рассмотреть дополнительную независимую проверку pin/certificate chain вне стандартного callback, не заменяя стандартную TLS-валидацию и не вводя самописную криптографию. Подпись запросов — перенос критичной части алгоритма в native layer, усложнение интерфейса вызова и дополнительная обфускация. Границы эффективности клиентских мер — клиентские защиты повышают стоимость анализа, но не гарантируют абсолютную защиту бизнес-логики.

5) Пакеты аудита

Рекомендуемый формат старта: ознакомительный review или первичная оценка устойчивости. Такой подход позволяет познакомиться с методикой проверки, увидеть формат итогового отчета, получить первичную картину рисков и согласовать оптимальный scope дальнейшего аудита.

Общие условия. Аудит может быть расширен при необходимости и по согласованию с клиентом. При переходе к более глубокому формату стоимость меньшего аудита будет зачтена в стоимость большего.

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

Возможна и обратная ситуация: если аудит на раннем этапе показывает отсутствие защит или наличие только тривиальных защит, аудит по согласованию может быть сокращен с уменьшением стоимости, либо фокус может быть перенесен на конкретную область — например API abuse, business logic, request signing, antifraud-сигналы или server-side enforcement — чтобы сохранить практическую ценность аудита в рамках согласованной стоимости.

1. Ознакомительный review. Срок: до 7 рабочих дней. Стоимость: 20 000–50 000 ₽. Цель: знакомство с подходом к проверке, уровнем технической экспертизы и форматом итогового отчета. Описание: краткий обзор приложения, архитектуры защит и потенциальных направлений дальнейшего анализа. Может быть точечным или обзорным по всем ключевым областям оценки.

2. Первичная оценка устойчивости. Срок: 1–2 недели. Стоимость: 150 000–250 000 ₽. Цель: определить наличие защит и уровень зрелости приложения. Описание: быстрая проверка всех ключевых доменов на наличие и базовую эффективность защит. Позволяет понять, где есть очевидные риски и какие области требуют дальнейшего анализа.

3. Стандартный аудит устойчивости. Срок: 2–4 недели. Стоимость: 250 000–500 000 ₽. Цель: понять, как обходятся имеющиеся защиты, оценить стоимость атаки и практические бизнес-риски. Описание: проверка всех доменов: API, подписи, certificate pinning, runtime instrumentation, модификация клиента, клиентская бизнес-логика и компенсирующие backend-контроли.

4. Углубленный аудит устойчивости. Срок: 4–6 недель. Стоимость: 500 000–800 000 ₽. Цель: достичь максимальной уверенности в устойчивости приложения и проверить защиту в рамках согласованного scope. Описание: формат для зрелых приложений с сильными защитами. Включает глубокий статический и динамический анализ, обход сложных механизмов защиты, проверку API, подписи, native-компонентов, anti-Frida, anti-tamper и server-side контролей.

5. Выборочный аудит. Срок: 1–2 недели на область. Стоимость: 150 000–250 000 ₽. Цель: проверить конкретную область или конкретный защитный механизм. Описание: формат подходит, когда уже есть понимание проблемной зоны или приоритетного риска. Например: request signing, certificate pinning, anti-Frida / anti-hook, перепаковка клиента, воспроизводимость API, client-side business logic или server-side enforcement. Важно: scope может быть расширен, если в ходе проверки становится ясно, что выбранная область связана с другими защитными механизмами или backend-контролями.

6. Разбор инцидента. Срок: по договоренности. Стоимость: по договоренности. Цель: разобраться в конкретном инциденте, abuse-сценарии или подозрительной активности. Описание: анализируются доступные артефакты: APK, API-запросы, признаки автоматизации, нестандартные последовательности действий, обходы клиентских ограничений и возможные пробелы в backend-контролях. Результат: описание вероятной причины инцидента, затронутых механизмов, бизнес-влияния и рекомендаций по снижению риска повторения.