Смартфон як мішень: хто відповідає, коли зламали мобільний додаток?

Уявіть картину: користувач завантажує ваш додаток, вводить дані картки, натискає «оплатити» – і через три дні дізнається, що його рахунок спустошено. Він не натискав жодних підозрілих посилань, не відповідав на фішингові листи, а просто користувався вашим продуктом.

Хто винен? Відповідь незручна: скоріше за все – власник додатка.

З власного досвіду знаємо, що мобільна кібербезпека – це та тема, яку, на жаль, стартапи та власники продуктів відкладають "на потім". Спочатку MVP, потім залучення, потім монетизація – і десь далеко в беклозі висить тікет "розібратися з безпекою". Але кіберзлочинці не чекають, поки ви дозрієте.

Смартфон – найзручніша мішень

Смартфон сьогодні – це гаманець, паспорт, щоденник і ключ від квартири в одному пристрої. Він завжди в мережі. Він завжди з нами. І на ньому – десятки додатків, кожен із яких має доступ до різних шматочків нашого цифрового життя. Через це мобільні пристрої стали однією із найпоширеніших точок входу для атак.

Але, на нашу думку, треба розрізняти два типи загроз: ті, де відповідає користувач, і ті, де відповідає власник мобільного продукту.

Є зона користувача і є зона мобільного додатка. Не варто їх плутати.

Коли провина на користувачеві

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

Аналогія: якщо хтось відчиняє двері незнайомцю, який представився сантехніком, і той виносить телевізор – це не вина виробника замка на вхідних дверях.

Коли провина на власниках мобільних застосунків

А тепер інша ситуація: користувач нікуди не переходив, нічого підозрілого не робив – але дані злили з вашого сервера. Або ваш SDK передавав токени у незашифрованому вигляді. Або зловмисник зміг підмінити відповідь вашого API через незакриту вразливість.

Це вже не помилка користувача. Це системна діра у вашому продукті. І відповідає за неї той, кому належить мобільний додаток, – юридично, репутаційно, а часто й фінансово.

Саме тут і проходить межа: якщо загроза прийшла через додаток – відповідальність переходить до його власника. І тому важливість кібербезпеки для бізнесу важко переоцінити.

Чим може закінчитися ігнорування заходів кібербезпеки мобільних додатків

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

Але це помилкова думка тих, хто не знає, що таке кібератаки. Насправді малі продукти – ідеальна мішень саме тому, що вони менше захищені. Автоматизовані сканери не розрізняють стартап і Enterprise – вони шукають відкриті порти, вразливі бібліотеки та незашифровані токени незалежно від розміру компанії. Існують десятки типів вразливостей кібербезпеки, і кожен з них може стати потенційною точкою входу для зловмисника.

Ціна такої помилки висока: один серйозний інцидент – і ви втрачаєте довіру користувачів, потрапляєте під регуляторні перевірки (особливо якщо обробляєте персональні дані або платежі) або й взагалі – ліквідуєте бізнес.

Це добре видно на прикладі одного з кейсів Datami. До нас звернулася технологічна компанія, яка готувала мобільний застосунок до релізу й хотіла перевірити, чи немає в ньому критичних ризиків до виходу на ринок. Під час пентесту з елементами реверс-інжинірингу команда Datami перевірила логіку авторизації, обробку даних, API та внутрішні компоненти застосунку. У результаті були виявлені критичні та середні вразливості, які потенційно могли призвести до витоку конфіденційної інформації або несанкціонованого доступу.

Цей кейс показує важливу річ: небезпечні вразливості не обов’язково з’являються у «зрілих» продуктах після років роботи на ринку. Вони можуть бути закладені ще до релізу – у логіці авторизації, API, обробці помилок або валідації даних. І якщо їх не знайти на етапі тестування, після запуску це вже буде не технічний недолік, а реальний бізнес-ризик.

Що потрібно зробити для захисту мобільних додатків

Ось що ми рекомендуємо власникам мобільного продукту:

1. Захистіть канал передачі даних

Весь трафік між додатком і сервером має йти виключно через HTTPS із валідними сертифікатами. Але навіть цього недостатньо – впровадьте SSL Pinning: це не дозволить зловмиснику підмінити сертифікат і перехопити дані навіть у захищеній мережі.

Аналогія: HTTPS – це як бронедвері, SSL Pinning – додаткова перевірка, що людина за дверима справді та, за кого себе видає.

2. Не зберігайте зайвого на пристрої

Мінімізуйте те, що залишається на смартфоні користувача. Якщо дані треба зберігати, використовуйте Keychain (для iOS) або Keystore (для Android), а не звичайні незашифровані SharedPreferences або локальну базу даних без шифрування. Токени, паролі, ключі сесій повинні бути або у захищеному сховищі, або не зберігатися взагалі.

3. Реалізуйте правильну автентифікацію

• Обов'язковий MFA для чутливих дій (зміна пароля, великі транзакції, зміна email).
• Короткий час життя токенів та їх обов'язкова інвалідація після виходу.
• Захист від brute-force: rate limiting, капча або тимчасове блокування після N невдалих спроб.
• Жодних паролів у логах – звучить банально, але ми з цим стикаємося дуже часто.

4. Перевіряйте сторонні бібліотеки та SDK

Мобільний додаток – це не лише код. Він складається з десятків залежностей: аналітика, реклама, платежі, пуш-повідомлення. Кожна бібліотека – потенційна точка входу.

Регулярно оновлюйте залежності. Перевіряйте їх за допомогою OWASP Dependency-Check або аналогічних інструментів. Якщо SDK не оновлювався два роки – це привід замінити його або принаймні глибоко перевірити.

На практиці ми часто бачимо, що слабке місце може бути не лише в коді самого додатка, а й у середовищі, де він працює: контейнерах, мережевій взаємодії, конфігураціях, залежностях і допоміжних сервісах. Наприклад, під час white-box пентесту серверів у Docker-контейнерах компанії-розробника програмного забезпечення для медичних, фінансових і real estate-продуктів команда Datami виявила 9 вразливостей, пов’язаних з ризиком доступу до баз даних через міжконтейнерну взаємодію. Цей приклад добре ілюструє: навіть якщо мобільний клієнт виглядає захищеним, бекенд, контейнерне середовище, SDK, бібліотеки та API-зв’язки також потрібно регулярно перевіряти. 

5. Захистіть API-рівень

Часто атака на мобільні додатки відбувається не через сам додаток, а через API. Перевірте:

• Чи захищені всі endpoints автентифікацією?
• Чи є rate limiting на критичних маршрутах?
• Чи не повертає API більше даних, ніж потрібно клієнту (over-fetching)?
• Чи логуєте ви аномальну активність і є реакція на неї?

6. Навчіть команду думати про безпеку

Security by design – це коли розробник на етапі планування фічі вже думає: «Яка вразливість тут може виникнути?». Це не вроджена якість, це навичка. 

Реагування на інциденти у разі витратніше ніж інвестиція в навчання команди.

7. Проводьте регулярну перевірку безпеки

Кібербезпека мобільного додатка – це не разова дія, а процес. Мінімум раз на рік (після оновлень або перед кожним великим релізом) рекомендуємо проводити:

• Penetration testing – зовнішня команда контрольовано імітує атаку на ваш продукт.
• SAST/DAST аналіз коду – автоматизований пошук вразливостей у коді та під час роботи запущеного застосунку.
• Огляд дозволів додатка – перевірка, чи застосунок просить лише те, що реально потрібно.

Що таке тестування на проникнення у мобільний додаток та як воно працює

Пентест мобільних застосунків (mobile application penetration testing) – це безпечна і контрольована імітація реальної атаки на ваш додаток, яку проводить команда фахівців з кібербезпеки. 

Мета пентесту – відшукати всі вразливі місця у захисті, щоб не дати шансів зловмиснику.

Ми рекомендуємо проводити перевірку кібербезпеки таким методом планово щороку, також перед кожним великим релізом або після суттєвих змін в архітектурі. Загрози оновлюються постійно, навіть якщо код вашого додатка залишається незмінним. Тому пентест варто проводити хоча б один раз на рік – незалежно від того, чи були зміни.

Що перевіряють під час тесту на проникнення у мобільний додаток

1. Клієнтська частина: як дані зберігаються, чи є чутлива інформація у відкритому вигляді, наскільки код захищений від реверс-інжинірингу.
2. Мережева взаємодія: чи можна перехопити трафік між додатком і сервером, чи коректно реалізовано SSL Pinning, чи захищені всі API-запити.
3. Автентифікація та авторизація: визначають, чи можна обійти вхід, отримати доступ до чужих даних, зловживати токенами сесій.
4. Бізнес-логіка: чи є способи маніпулювати функціями додатка – наприклад, змінити суму транзакції або отримати доступ до закритого функціоналу.

Як виглядає процес

Спочатку фахівці збирають інформацію про додаток і визначають поверхню атаки. Потім – активна фаза тестування на проникнення у мобільний застосунок із застосуванням ручних та автоматизованих методів. Після завершення перевірки клієнт отримує детальний звіт, який містить: 

• список знайдених вразливостей із рівнем критичності;
• пояснення, як їх можна експлуатувати;
• конкретні рекомендації щодо усунення помилок безпеки.

Якщо наші пентестери виявляють критичні вразливості, після їх виправлення ми безплатно проводимо ретест. 

Що отримує на виході власник мобільного додатка

Після тестування на проникнення у мобільний застосунок замовник отримує не просто список знайдених проблем, а повну картину реального стану безпеки свого продукту. Він уже точно знає, де є вразливі місця, наскільки вони критичні та що саме потрібно виправити – без здогадок і без "здається, все нормально".

Звіт про пентест – це по суті чіткий план дій: що усунути в першу чергу, що може зачекати і як побудувати захист так, щоб він працював довгостроково, а не до наступного релізу.

Окремий бонус – пентест-звіт як документ довіри. Для інвесторів, корпоративних клієнтів і партнерів наявність незалежної перевірки безпеки все частіше є обов'язковою умовою для початку співпраці.

І найважливіше: кожен долар, витрачений на пентест сьогодні, – це потенційно збережені десятки тисяч завтра. Ліквідація наслідків кіберінциденту, компенсації користувачам, репутаційні втрати – усе це коштує незрівнянно дорожче, ніж превентивна перевірка.

Висновки

Сьогодні мобільний застосунок має доступ не лише до екрана користувача, а й до його грошей, документів, контактів, повідомлень і персональних даних. Тому будь-яка вразливість у ньому – це не просто технічна помилка, а прямий ризик для людини та її довіри до вашого продукту.

Коли через застосунок відбувається витік даних, викрадення коштів або злам акаунта, відповідальність рідко сприймається як абстрактна. Користувач очікує, що продукт, якому він довірив свої дані, був належно захищений. І якщо інцидент став можливим через слабкі місця в додатку, пояснення на кшталт «користувач мав бути уважнішим» або «зловмисників неможливо зупинити» вже не працюють. Відповідальність переходить до власника продукту, який випустив його без достатнього рівня безпеки.

Хороша новина: більшість вразливостей у мобільних додатках можна виявити та усунути раніше, ніж їх використає зловмисник. Саме для цього існує тестування на проникнення у мобільний додаток. Не як формальність і не для звіту перед аудиторами чи інвесторами – а як реальна перевірка того, наскільки мобільний додаток готовий протистояти атаці. 

А ви готові дізнатися про вразливості свого цифрового ресурсу першими?

Терміни, які ми використали у цій статті