Після оновлення додатку в Google Play або App Store конкуренти отримують доступ до бази користувачів. Або хакер через вразливий deep link скидає пароль адміністратора. Такі сценарії — результат відсутності системного аудиту безпеки. Наші інженери з 5+ років досвіду та більше 100 проведених аудитів знаходять ці слабкі місця до того, як їх знайдуть зловмисники.
За даними OWASP, понад 80% мобільних додатків містять хоча б одну вразливість із Mobile Top 10. Усунення такої вразливості на етапі розробки обходиться в 30 разів дешевше, ніж після релізу. Тому аудит до публікації — розумна інвестиція. Ми поєднуємо статичний і динамічний аналіз з ручним пентестом, щоб покрити всі вектори атак. Нижче — як це працює.
Чому OWASP Mobile Top 10?
OWASP Mobile Top 10 — не формальний чек-лист, а структурований підхід до активного тестування. Кожен із 10 пунктів адаптується під архітектуру додатку: ми не просто звіряємося зі списком, а відтворюємо атаки в реальних умовах. Ось як ми це робимо.
Як підготуватися до аудиту?
- Зберіть актуальні бінарні файли (APK/IPA) та вихідний код, якщо доступний.
- Надайте документацію: опис архітектури, список сторонніх бібліотек, API-ендпоінти.
- Визначте критичні сценарії: аутентифікація, платежі, робота з персональними даними.
Як ми шукаємо вразливості: процес у деталях
Почнемо з найчастішого джерела ризику — некоректного зберігання секретів.
M1 та M2: Секрети, залежності та ланцюг постачання
Шукаємо захардкоджені credentials: API-ключі в коді, паролі в конфігураційних файлах, токени в git-історії. Інструменти: jadx + grep, truffleHog для репозиторію, аналіз AndroidManifest.xml та Info.plist. Перевіряємо зберігання: credentials у SharedPreferences/UserDefaults — вразливість. Має бути в Android Keystore / iOS Keychain. На jailbroken пристрої читаємо Keychain через objection keychain dump — дивимося, що там зберігається та з якими атрибутами доступу.
Сторонні залежності — часто найслабше місце. Перевіряємо версії бібліотек на відомі CVE (OWASP Dependency-Check, gradle dependencyInsight, pod-outdated), використання бібліотек із ненадійних джерел, дозволи, які запитують SDK аналітики та реклами. Окремо — CI/CD пайплайн: чи є secret scanning у репозиторії, підписання артефактів збірки, перевірка цілісності залежностей через hash verification.
Приклад вразливого коду
```java // вразливий код — приймає Intent extras без валідації String fileName = getIntent().getStringExtra("file_name"); File file = new File(getExternalFilesDir(null), fileName); // fileName = "../../../../../../data/data/com.other.app/secret.db" ```M3 та M4: Аутентифікація, авторизація та введення даних
Тестуємо обхід екрану авторизації через deep links (передаємо параметри в URL, які мають бути доступні лише авторизованим користувачам), горизонтальне підвищення привілеїв (авторизований користувач A звертається до даних користувача B, змінюючи user_id у запиті), відсутність ревалідації сесії при критичних операціях.
На практиці часто знаходимо: deep link myapp://reset-password?token=XXX обробляється без перевірки джерела intent — будь-який додаток може надіслати такий intent та ініціювати скидання пароля. Або зміна email у профілі не вимагає підтвердження поточного пароля.
На мобільному клієнті особливо актуальні: SQL-ін'єкції через параметри deep links або WebView URL, XSS у WebView з setJavaScriptEnabled(true), path traversal при роботі з файлами (URL типу ../../etc/passwd у параметрах завантаження файлу), небезпечна десеріалізація в Intent extras.
M5 та M8: Комунікації та конфігурація
Перевіряємо через Burp Suite proxy: наявність HTTPS для всіх ендпоінтів, certificate pinning (обходимо через Frida ssl-unpinning.js), дані в GET-параметрах URL (логуються серверами, проксі, CDN), небезпечні WebSocket з'єднання, витік чутливих даних у заголовках запитів. network_security_config.xml на Android — перевіряємо cleartextTrafficPermitted, наявність користувацьких CA в trust-anchors.
Safety Misconfiguration: android:debuggable="true" у продакшн-маніфесті відкриває налагоджувальний доступ. android:allowBackup="true" дозволяє adb backup на Android < 12 — із бекапу читаються SharedPreferences, бази даних. exported="true" у компонентів без перевірки intent. На iOS — ATS (App Transport Security) вимкнено через NSAllowsArbitraryLoads. Entitlements: надлишкові capabilities (наприклад, com.apple.developer.icloud-container-identifiers у додатку, який не використовує iCloud).
M6, M7 та M9: Дані, бінарний захист та зберігання
Права доступу: додаток запитує ACCESS_FINE_LOCATION постійно, хоча геолокація потрібна лише в конкретному сценарії? Або READ_CONTACTS без видимої функції роботи з контактами? Аналізуємо відповідність запитаних дозволів декларованій функціональності. Логи: adb logcat часто видає PII у продакшн-білді. Перевіряємо наявність чутливих даних у logcat, Crashlytics/Sentry повідомленнях, аналітичних подіях.
Декомпілюємо APK через jadx, IPA через Ghidra. Оцінюємо: читаність бізнес-логіки після декомпіляції, наявність та якість обфускації (R8/ProGuard/DexGuard), рядкові константи в plaintext, debug-флаги в продакшн-білді (BuildConfig.DEBUG, debuggable у маніфесті), наявність anti-tampering перевірок.
Повна ревізія сховищ даних на пристрої:
| Сховище | Що шукаємо | Інструмент |
|---|---|---|
| SQLite БД | Чутливі дані, відсутність шифрування | objection, sqlite3 |
| SharedPreferences / UserDefaults | Паролі, токени, ключі | objection data storage |
| Keychain (iOS) | Атрибути доступу, що саме зберігається | objection keychain dump |
| Файлова система | Незашифровані документи, кеш відповідей API | objection files ls |
| Буфер обміну | Автокопіювання чутливих даних | Ручне тестування |
M10: Слабка криптографія
Слабкі алгоритми: DES, 3DES, RC4, MD5 для паролів, ECB mode для блокових шифрів, передбачуваний seed у java.util.Random замість SecureRandom, нульовий або фіксований IV, відсутність MAC (використовується AES-CBC без HMAC). Реалізації кастомної криптографії замість стандартних бібліотек — червоний прапорець. «Своя крипта» майже завжди зламана.
Що дає аудит: результати та пріоритезація
По кожній із 10 категорій фіксуємо: знайдено/не знайдено, конкретні екземпляри вразливостей із CVSS оцінкою, кроки для відтворення, рекомендації з прикладами коду. Пріоритети: Critical (експлуатується без root/jailbreak, прямий доступ до даних) → High → Medium → Low (інформаційні знахідки).
Порівняння методів тестування
| Тип аналізу | Час виконання | Глибина покриття | Частка виявлених вразливостей |
|---|---|---|---|
| Статичний | 1–2 дні | Код + залежності | 60–70% |
| Динамічний | 2–3 дні | Runtime + мережа | 40–50% |
| Ручний пентест | 3–5 днів | Логіка + бізнес | 80–95% |
Ручне тестування виявляє до 95% вразливостей — це на 30% більше, ніж автоматичний скринінг. Статичний аналіз виявляє 60-70% вразливостей, ручний пентест — до 95%, що в 1.5 рази більше. Тому в нашому аудиті поєднуються всі три типи.
Які інструменти використовуються?
Ми використовуємо промислові та open-source інструменти: Burp Suite, Frida, Objection, jadx, Ghidra, OWASP Dependency-Check, truffleHog та інші. Повний список надається в звіті.
Що входить в аудит?
- Звіт з детальним описом вразливостей, CVSS-оцінками, кроками відтворення та прикладами коду.
- Рекомендації щодо усунення кожної знахідки з пріоритетами.
- Повторне тестування (ретест) після виправлень (за домовленістю).
- Консультація з командою розробників для роз'яснення результатів.
- Гарантія конфіденційності: всі дані захищені NDA.
Аудит типового додатку середнього масштабу за OWASP Top 10 — 3–5 робочих днів. Включає статичний аналіз, динамічне тестування на рутованому Android та jailbroken iOS, аналіз трафіку. Обсяг документації — згідно з вимогами замовника.
Вартість аудиту починається від $1000 за додаток середньої складності. Усунення вразливостей на етапі розробки обходиться в 30 разів дешевше, ніж після релізу, що забезпечує економію до 40% бюджету.
Напишіть нам для безкоштовної оцінки вашого проекту — наші експерти зв'яжуться з вами протягом години. Замовте аудит безпеки вашого мобільного додатку під ключ прямо зараз.