OWASP Mobile Top 10: какво е това, списък на уязвимостите и как да се прилага

Какво е OWASP Mobile Top 10?

OWASP Mobile Top 10 е стандартизиран списък на най-критичните рискове за сигурността, характерни именно за мобилните приложения. За разлика от общия OWASP Top 10 за уеб приложения, мобилната версия взема предвид спецификите на платформите: локално съхранение на устройството, взаимодействие със сензори, офлайн режими и особености на магазините за приложения. Документът се публикува от 2010 г. и се преразглежда на всеки 2–4 години: актуалната версия за 2024 г. включва категории като M1 — Improper Credential Usage и M8 — Security Misconfiguration. Проектът се поддържа от общност от над 500 доброволци по целия свят.

История и цел на създаване

Първоначално OWASP Top 10 покриваше само уеб приложения, но растежът на мобилната разработка през 2010-те години изиска отделен документ. Първата версия на Mobile Top 10 излезе през 2011 г. и съдържаше само 7 точки. До 2024 г. списъкът се разшири до 10 категории, всяка от които включва няколко конкретни сценария на атака. Основната цел на документа е да даде на разработчиците и екипите за сигурност общ език за обсъждане на рисковете и приоритизиране на корекциите. Редовното актуализиране на списъка отразява промените в ландшафта на заплахите: появата на нови API, еволюцията на операционните системи (Android, iOS) и нови техники за атака, описани в докладите на Positive Technologies и други изследователски центрове.

Как се формира списъкът OWASP Mobile Top 10

Методологията за съставяне на Mobile Top 10 се основава на данни от реални проекти: анализират се резултатите от тестове за проникване на мобилни приложения, доклади за инциденти и изследвания на уязвимости. Всяка категория се оценява по два параметъра: честота на поява (Incidence Rate) и потенциално техническо въздействие (Technical Impact). Комбинацията от тези показатели формира крайната класация. За разлика от субективните списъци, OWASP използва отворени данни: всеки член на общността може да подаде заявка за добавяне на нова категория чрез хранилището на проекта в GitHub. За актуалната версия 2024 г. са обработени над 300 хиляди теста за сигурност от 25 държави, което прави статистиката представителна за глобалната екосистема за мобилна разработка. Допълнително OWASP публикува MASVS (Mobile Application Security Verification Standard) — набор от подробни изисквания за сигурност, който включва над 80 конкретни проверки, разпределени в 8 категории. MASVS се използва като основа за сертифициране на приложения и като контролен списък за тестове за проникване: всяко изискване има препратка към категория от Mobile Top 10, което осигурява пълна проследимост между стандарта и списъка с рискове.

Преглед на ключовите уязвимости

Нека разгледаме трите най-критични категории от OWASP Mobile Top 10 2024, които покриват повече от 70% от всички инциденти със сигурността в мобилни проекти. Всяка категория включва конкретни сценарии на експлоатация и препоръки за защита.

Неправилно използване на платформата

Тази категория (M1) обхваща ситуации, в които разработчиците използват API и механизми на платформата не по предназначение. Типични примери: Intent Injection на Android, отворени манипулатори на Deep Link на iOS, неправилна работа с Keychain и SharedPreferences. Нападател може да изпрати специално създаден Intent и да получи достъп до данни на друго приложение или компонент. Според доклад на NowSecure (2023) 22% от тестваните Android приложения съдържаха уязвимости от тип Intent Redirection. Защитата включва: строга валидация на входни данни, проверка на източника на Intent и използване на разрешения за експортирани компоненти.

Несигурно съхранение на данни

Несигурно съхранение на данни (M2) е най-често срещаният проблем в мобилните приложения. Възниква, когато поверителни данни (токени за достъп, пароли, лични данни) се съхраняват в отворен вид или с недостатъчна защита. Типични източници на уязвимост: SQLite бази данни без криптиране, SharedPreferences без EncryptedSharedPreferences, записване на данни в режим за отстраняване на грешки. Според OWASP Foundation (2024) повече от 60% от безплатните приложения в Google Play съхраняват поне един тип поверителни данни в некриптиран вид. Решение — използване на Android EncryptedSharedPreferences, iOS Keychain и криптиране на данни преди запис в локалното хранилище.

Несигурна комуникация

Категория M3 — несигурна комуникация — включва уязвимости в каналите за предаване на данни между приложението и сървъра. Липса на HTTPS, неправилна валидация на SSL сертификати, използване на остарели протоколи TLS 1.0/1.1 — всички тези проблеми позволяват на нападателя да прихваща трафика чрез Man-in-the-Middle атаки. Особено опасна е ситуацията, когато приложението работи с чувствителни данни (банкови транзакции, медицинска информация) през незащитен канал. През 2023 г. изследователи от NCC Group откриха, че 12% от популярните финансови приложения използват неправилна конфигурация на TLS. Препоръка: задължително използване на HTTPS с Certificate Pinning и отказ от HTTP в производствените компилации.

Как да тестваме приложения според OWASP Mobile Top 10

Тестването на сигурността на мобилно приложение според методологията на OWASP включва няколко етапа: статичен анализ на кода (SAST), динамичен анализ (DAST) и ръчно тестване (pentest). Всеки етап е насочен към идентифициране на определени категории уязвимости от Mobile Top 10.

Инструменти за тестване

За автоматизиран анализ OWASP препоръчва използването на MobSF (Mobile Security Framework) — инструмент с отворен код. MobSF извършва статичен анализ на изходния код и двоични файлове, проверява конфигурацията на манифестите, анализира разрешенията и идентифицира уязвимости от Mobile Top 10. За динамичен анализ се използват Burp Suite (прокси за прихващане на трафик) и Frida (инструмент за runtime анализ). Комбинацията от тези инструменти покрива повече от 80% от категориите в списъка. Редовното тестване в CI/CD тръбопровод с MobSF позволява идентифициране на уязвимости в ранните етапи на разработка и намалява разходите за тяхното отстраняване с 60–70%. Интегрирането на SAST и DAST инструменти в тръбопровода трябва да бъде автоматизирано чрез Gradle/Maven приставки или Fastlane стъпки в iOS компилации.

Интерпретация на доклада на MobSF

След стартиране на MobSF разработчикът получава доклад с цветни индикатори: червен — критична уязвимост, оранжев — среден риск, жълт — нисък. Всяко предупреждение съдържа препратка към съответната категория OWASP Mobile Top 10, описание на проблема и препоръка за отстраняване. Важно е не само да премахнете червените предупреждения, но и да анализирате оранжевите: много от тях (напр. експортиран Activity без защита) в комбинация могат да дадат вектор за атака на нападателя. Препоръчва се постигане на нулев брой червени предупреждения и не повече от 2–3 оранжеви преди всяко пускане. Докладът на MobSF включва също анализ на разрешенията на приложението: всякакви излишни разрешения (напр. достъп до камера в калкулатор) се отбелязват като нарушение на принципа на минималните привилегии и трябва да бъдат премахнати от манифеста. За iOS приложения MobSF извършва подобен анализ на .ipa файлове, включително проверка на Info.plist за ATS изключения и анализ на Mach-O двоични файлове за използване на несигурни API като NSAllowsArbitraryLoads.

class InsecureStorage {
    private val prefs = context.getSharedPreferences("my_app", Context.MODE_PRIVATE)

    fun saveToken(token: String) {
        prefs.edit().putString("auth_token", token).apply()
    }

    fun getToken(): String? {
        return prefs.getString("auth_token", null)
    }
}

class SecureStorage(context: Context) {
    private val masterKey = MasterKey.Builder(context)
        .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
        .build()

    private val securePrefs = EncryptedSharedPreferences.create(
        context,
        "secure_prefs",
        masterKey,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )

    fun saveToken(token: String) {
        securePrefs.edit().putString("auth_token", token).apply()
    }
}