OWASP Mobile Top 10: розбираємо загрози для iOS та Android

Мобільний застосунок сьогодні – це точка доступу до даних користувача, платежів і бізнес-логіки. Будь-яка вразливість у цій точці напряму перетворюється на ризик: витік даних, злам акаунтів, фінансові втрати. OWASP TOP 10 – що це таке?
OWASP Mobile Top 10 – це практичний стандарт, який показує, де саме мобільні застосунки найчастіше ламаються з точки зору безпеки.

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

Якщо застосунок працює з авторизацією, персональними даними або платежами – ігнорувати ці загрози вже не можна.

OWASP Mobile Top 10 – це список найбільш критичних вразливостей мобільних застосунків для iOS та Android, сформований на основі реальних атак і практики безпеки. Особливо важливо для:

• продуктових компаній з мобільними застосунками;
• фінтех і e-commerce проєктів;
• стартапів з авторизацією та користувацькими даними;
• команд, які планують масштабування продукту.

Його використовують для аудиту застосунку та перевірки безпеки перед релізом. Якщо застосунок зберігає або обробляє дані користувача – OWASP TOP 10 це базовий рівень безпеки, навіть якщо застосунок зібраний через конструктор (детальніше в огляді конструкторів мобільних застосунків).

OWASP 10 відрізняється від веб-версії тим, що фокусується на ризиках клієнтського середовища – пристрою користувача, а не тільки серверної частини. У мобільних застосунках зона довіри зміщується: частина логіки, даних і взаємодій виходить за межі контрольованої інфраструктури.

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

Друга різниця – локальне зберігання даних. Токени та користувацька інформація можуть зберігатися на пристрої і витягуватись без належного захисту.

Третя – неконтрольоване середовище виконання. Root/jailbreak, емулятори та модифіковані пристрої дозволяють втручатися в роботу застосунку.

Четверта – перехоплення трафіку. Без додаткового захисту запити можна аналізувати і підміняти.

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

Кожна категорія описує не абстрактну проблему, а конкретний сценарій, через який зловмисник може отримати доступ до даних, логіки або управління застосунком. Далі, топ 10 вразливостей OWASP:

M1: Неналежне використання платформи (Improper Platform Usage)

Це помилки у використанні вбудованих механізмів безпеки iOS та Android. Проявляється, коли:

• неправильно налаштовані permissions;
• ігноруються secure API платформи;
• використовується небезпечна робота з WebView.

Ризик – обхід системного захисту пристрою та доступ до чутливих даних.

M2: Небезпечне зберігання даних (Insecure Data Storage)

Дані зберігаються на пристрої без захисту або шифрування. Типові випадки:

• токени у plain text;
• дані в SQLite без шифрування;
• кеш із персональною інформацією.

При доступі до пристрою зловмисник отримує облікові дані та дані користувача.

M3: Небезпечна передача даних (Insecure Communication)

Дані передаються між застосунком і сервером без достатнього захисту. Проявляється через:

• відсутність HTTPS;
• відсутність certificate pinning;
• вразливість до MITM-атак.

Ризик – перехоплення і зміна даних у процесі передачі.

M4: Небезпечна аутентифікація (Insecure Authentication)

• Помилки в логіці входу та перевірки користувача. Типові проблеми:
  слабка перевірка токенів;
• відсутність захисту від brute force;
• неправильна робота із сесіями.

Таким чином можливий несанкціонований доступ до акаунтів.

M5: Недостатня криптографія (Insufficient Cryptography)

Використання слабких або застарілих методів шифрування. Проявляється, коли:

• використовуються небезпечні алгоритми;
• неправильно реалізовано шифрування;
• ключі зберігаються в коді.

Залишається можливість розшифрування даних і компрометація безпеки.

M6: Небезпечна авторизація (Insecure Authorization)

• Відсутність або неправильна перевірка прав доступу. Типові сценарії:
  користувач отримує доступ до чужих даних;
• backend не перевіряє права;
• логіка доступу реалізована на клієнті.

Ризик – витік даних і порушення бізнес-логіки.

M7: Якість клієнтського коду (Client Code Quality)

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

• небезпечні бібліотеки;
• відсутність обробки помилок;
• вразливості в логіці.

Можлива експлуатація багів для обходу захисту або доступу до даних.

M8: Підробка коду (Code Tampering)

Зміна коду застосунку після встановлення. Типові сценарії:

• модифікація APK/IPA;
• впровадження шкідливого коду;
• обхід вбудованої логіки.

Ризик – зміна поведінки застосунку і обхід обмежень.

M9: Зворотна розробка (Reverse Engineering)

Аналіз застосунку з метою отримання логіки і даних. Проявляється, коли:

• код не захищений;
• відсутня обфускація;
• чутливі дані знаходяться в коді.

Є можливість розкриття API, ключів, бізнес-логіки.

M10: Зайва функціональність (Extraneous Functionality)

У застосунку залишається функціональність, не призначена для користувача. Типові випадки:

• тестові endpoints;
• debug-інструменти;
• приховані функції.

Можливе використання цих функцій для атаки або обходу захисту.

Загрози відрізняються точкою атаки. На Android частіше атакують середовище і сам застосунок, на iOS – логіку і API.

Android більш відкритий: можливий sideloading, root-доступ і модифікація APK, що важливо враховувати при розробці застосунків на Android. Це дозволяє змінювати поведінку застосунку, обходити перевірки і витягувати дані.

iOS обмежує встановлення і ізолює застосунки, тому пряме втручання складніше, що знижує ризики при розробці застосунків для iPhone. Основні ризики – помилки в авторизації, зберіганні даних і перевірці доступу на сервері.

Наприклад, на Android можна модифікувати застосунок і відключити клієнтські перевірки. На iOS – отримати доступ до чужих даних, якщо backend некоректно перевіряє права.

Вразливості OWASP Mobile Top 10 закриваються не точково, а через архітектуру, де клієнту не довіряють, що напряму залежить від обраного стеку (детально технології розробки iOS-застосунків), а критична логіка і перевірки винесені на сервер.

Спочатку потрібно мінімізувати довіру до клієнта. Не зберігати чутливі дані у відкритому вигляді, не реалізовувати бізнес-логіку на стороні застосунку, всі перевірки прав виконувати на backend.

Потім важливо захистити дані і передачу. Використовувати тільки HTTPS, впроваджувати certificate pinning, зберігати токени у захищених сховищах (Keychain / Secure Storage), не кешувати критичні дані.

Контролювати середовище і цілісність застосунку. Перевіряти root/jailbreak, впроваджувати захист від модифікації та обфускацію коду, виключати debug-функції з продакшену.

Обов’язково коректно реалізувати аутентифікацію та авторизацію. Використовувати короткоживучі токени, оновлення через refresh, перевірку прав на сервері, захист від brute force.

І наостанок важливо виключити зайву функціональність і вразливий код. Видаляти тестові endpoints, не зберігати ключі в коді, використовувати тільки перевірені бібліотеки.

Перевірка будується на поєднанні автоматичних інструментів і ручного аналізу (детальніше у чек-листі тестування мобільного застосунку), оскільки види вразливостей web застосунків пов’язані з логікою, а не тільки з кодом.

1. Статичний аналіз (SAST). Перевіряється код і збірка застосунку: зберігання даних, використання криптографії, наявність ключів і небезпечних бібліотек.
2. Динамічний аналіз (DAST). Застосунок тестується в роботі: перехоплення трафіку, перевірка HTTPS, спроби MITM-атак, аналіз запитів до API.
3. Тестування середовища. Запуск на root/jailbreak пристроях і емуляторах, перевірка стійкості до модифікації і втручання.
4. Перевірка логіки і доступу. Тестуються сценарії авторизації і авторизації: чи можна отримати доступ до чужих даних, обійти обмеження або змінити поведінку застосунку.
5. Пентест. Імітація реальної атаки зі спробою витягнути дані, обійти захист і знайти слабкі місця.

OWASP ТОП 10 використовується як чек-лист – кожна категорія перевіряється окремо через код, поведінку застосунку і взаємодію з сервером.

Якщо використовувати OWASP як чек-лист, він закриває ключові точки: де зберігаються дані, як вони передаються, хто і як отримує доступ, чи можна втрутитися в роботу застосунку. Це дозволяє побачити реальні сценарії атак до того, як ними скористаються.

Практичний підхід простий: кожна категорія OWASP має бути обов’язково перевірена – на рівні архітектури, розробки і тестування.

Головне – не відкладати безпеку на фінальний етап. Чим раніше вона вбудована в продукт, тим дешевше і ефективніше її реалізувати.

OWASP top 10 – це базовий стандарт, який варто використовувати як обов’язковий чек-лист перед релізом. Пройдіть його для свого застосунку – і ви закриєте більшість критичних вразливостей ще до того, як вони перетворяться на проблему.