RASP — що це, принцип роботи та захист у реальному часі

Що таке RASP?

Runtime Application Self-Protection (RASP) — технологія безпеки, що інтегрується в додаток на етапі збірки або через runtime-агент. RASP аналізує поведінку додатка під час виконання та приймає рішення про блокування атак на основі контексту: звідки надійшов виклик, які дані передаються, який стан стеку. На відміну від сигнатурних систем, RASP не шукає відомі патерни атак — він виявляє аномальну поведінку, що відхиляється від очікуваного сценарію виконання коду.

Концепцію RASP було формалізовано Gartner у 2011 році, а перші комерційні реалізації з’явилися у 2014–2015 роках. Для мобільних платформ RASP почав активно застосовуватися з 2017 року, коли ринок усвідомив недостатність традиційної обфускації. За даними звіту MarketsandMarkets (2025), обсяг ринку RASP-рішень становить 2,8 млрд USD при річному зростанні 24,5%. Впровадження RASP рекомендується стандартами OWASP Mobile Top 10 та PCI DSS 4.0 для додатків, що обробляють платіжні дані.

RASP працює на двох рівнях: перехоплення та оцінка. Перехоплення — перехоплення системних і бібліотечних викликів через хуки, що вбудовуються в код на етапі збірки або в runtime через динамічну інструментацію. Оцінка — аналіз контексту виклику: перевірка вхідних параметрів, стеку викликів, стану sandbox, наявності налагоджувача. Рішення приймається на основі політики безпеки, яку задає розробник. Політика може бути жорсткою (блокувати), м’якою (логувати) або адаптивною (змінювати поведінку залежно від рівня загрози).

Як працює RASP: архітектура та механізми

Архітектура RASP-агента складається з трьох компонентів: рівень інструментації, аналізатор та політика. Рівень інструментації перехоплює системні виклики та виклики фреймворку. Аналізатор перевіряє контекст на відповідність очікуваним патернам. Політика визначає реакцію.

Інструментація коду

Для мобільних додатків використовується compile-time інструментація: байткод або нативний код модифікується на етапі збірки — перед кожним небезпечним викликом вставляється перевірка. Компілятор RASP-агента модифікує точки входу FileOutputStream.write(), Runtime.exec(), Class.forName() та android.app.Activity.onStart(). Для Android використовується трансформація DEX-байткоду через Gradle plugin; для iOS — модифікація Mach-O бінарника через post-link скрипт.

Аналіз контексту

При перехопленні виклику RASP аналізує: caller клас та метод (хто викликає), stack trace (ланцюжок викликів), аргументи (дані, що передаються), return value (що повертається), timestamp та thread id. Аномалія фіксується, коли, наприклад, Runtime.exec() викликається не з UI-потоку та не з коду додатка, а з бібліотеки, завантаженої через JNI з нестандартним шляхом. Або коли FileOutputStream.write() отримує дані, що містять виконуваний байткод замість очікуваного PNG-заголовка.

Політики реагування

RASP підтримує три типи реагування: Block — аварійне завершення додатка при виявленні атаки, Log — відправка деталей інциденту на сервер збору логів без зупинки додатка, Deceive — підміна повернутого значення на фальшиве, щоб атакуючий отримав некоректні дані. Комбінація Log та Deceive дозволяє збирати розвідувальні дані про атакуючого, не розкриваючи факт виявлення.

// Приклад: RASP-перевірка виклику Runtime.exec()
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // Перевірка caller
        String caller = stack[1].getClassName();

        // Якщо виклик не з нашого пакета — підозріло
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Перевірка команди на чорний список
        String[] blocked = {"su", "frida", "ptrace", "/data/local"};
        for (String pattern : blocked) {
            if (command.contains(pattern)) {
                SecurityPolicy.reportIncident(
                    "BLOCKED_CMD", command, stack
                );
                return new Process(); // deceiving: порожній процес
            }
        }

        return null; // дозволити виконання
    }
}

RASP vs WAF та інші засоби захисту

RASP часто порівнюють з Web Application Firewall (WAF), але принципова відмінність — у позиціонуванні. WAF знаходиться на периметрі мережі та аналізує тільки HTTP-запити. RASP працює всередині додатка та бачить логіку обробки.

На відміну від обфускації (ProGuard, DexGuard), яка робить код нечитабельним, RASP активно виявляє атаки в процесі експлуатації. Обфускація — пасивний захист: якщо атакуючий витратив достатньо часу на reverse engineering, код буде прочитано. RASP — активний: він бачить, що атакуючий намагається налагоджувати додаток, і реагує до того, як буде прочитано хоча б один рядок коду. Комбінація обфускації + RASP дає багатошаровий захист, де обфускація уповільнює аналіз, а RASP перериває атаку на етапі інструментації.

RASP у мобільних додатках

Мобільні RASP-рішення адаптовані під специфіку Android та iOS. На відміну від серверних Java-додатків, мобільні RASP-агенти працюють в умовах обмеженої пам’яті та акумулятора, що потребує легкої інструментації.

RASP на Android

На Android RASP-агент вбудовується через Gradle plugin, що модифікує DEX-байткод на етапі збірки. Агент перехоплює понад 50 системних викликів, включаючи: Runtime.exec() для виявлення запуску su або Frida, Class.forName() для виявлення завантаження підозрілих класів, System.loadLibrary() для контролю завантаження нативних бібліотек з нестандартних шляхів. Додатково перевіряється наявність у /proc/self/maps бібліотек frida-agent, frida-helper, libinject та substrate.

RASP на iOS

На iOS RASP реалізується через постобробку Mach-O бінарника. Для iOS складність вища через суворі вимоги Apple до модифікації бінарників. Агент перехоплює виклики функції fork(), dlopen(), ptrace() та перевіряє наявність CydiaSubstrate.dylib у завантажених бібліотеках. RASP для iOS не може модифікувати код в App Store білді — тільки для Enterprise-розповсюдження. Для App Store рекомендується використовувати compile-time інструментацію через Swift Macro або Objective-C method swizzling.

Детектування інструментів аналізу

Мобільний RASP виявляє: Frida (через перевірку /proc/self/maps та /data/local/tmp/frida*), Xposed Framework (через перевірку de.robv.android.xposed.XposedBridge в ClassLoader), налагоджувач JDWP (через Debug.isDebuggerConnected()), емулятори (через перевірку Build.FINGERPRINT, Build.HARDWARE, Build.MODEL) та прапорець debuggable в AndroidManifest. За даними NowSecure Mobile Threat Report (2025), RASP-агент виявляє 89–97% інструментованих сесій Frida.

Реалізація RASP-агента на практиці

Впровадження RASP у мобільний додаток потребує налаштування інструментації, визначення політик та інтеграції з SIEM-системою для збору логів інцидентів.

Вибір реалізації: compile-time vs runtime

Compile-time інструментація — модифікація байткоду на етапі збірки, не впливає на продуктивність у runtime. Runtime інструментація (через Java Agent на сервері або Frida на клієнті) — більш гнучка, але додає 5–10% накладних витрат. Для мобільних додатків рекомендується compile-time підхід, оскільки він не потребує постійного підключення до мережі та не витрачає заряд батареї на аналіз.

Інтеграція з існуючими бібліотеками

RASP-агент повинен коректно працювати з популярними SDK. Firebase Crashlytics, Google Analytics та Appsee не повинні блокуватися. Налаштування whitelist для відомих бібліотек обов’язкове. У конфігурації агента задаються винятки: якщо виклик надходить з класу com.google.firebase — перевірка пропускається. Whitelist оновлюється з кожним релізом SDK.

Приклад обробки інциденту

При виявленні Frida через RASP-агент відбувається: збір контексту (stack trace, версія ОС, час), відправка даних на сервер логування в зашифрованому вигляді, виконання політики (crash, log-only або deceive), інкремент лічильника для визначення масової атаки. Дані з різних пристроїв агрегуються на сервері для виявлення патернів атак.

class RASPManager {
    fun analyzeAndReact() {
        val threats = detectThreats()
        if (threats.isNotEmpty()) {
            val report = ThreatReport().apply {
                threats = threats
                timestamp = System.currentTimeMillis()
                deviceId = DeviceInfo.getHashedId()
                stackTrace = Thread
                    .currentThread()
                    .stackTrace
                    .take(10)
                    .toList()
            }

            val policy = SecurityPolicy.getPolicy(threats.maxBy { it.severity })

            when (policy) {
                Policy.BLOCK   -> throw SecurityException("Protection triggered")
                Policy.LOG     -> ServerLogger.sendReport(report)
                Policy.DECEIVE -> DeceptionLayer.activate(report)
            }
        }
    }
}

Обмеження та хибні спрацьовування

RASP не є срібною кулею. Технологія має обмеження, які необхідно враховувати при проектуванні захисту.

Продуктивність

Кожен перехоплений виклик додає перевірку контексту. При агресивній конфігурації (перехоплення всіх IO та exec-викликів) продуктивність може впасти на 5–15%. Для мобільних додатків критичний час запуску: RASP-ініціалізація додає 200–500 мс на старті. Рекомендується точкова інструментація — тільки критичні функції, а не всі можливі. Профілювання з RASP-агентом обов’язкове на етапі тестування.

Хибні спрацьовування

RASP може блокувати легітимну поведінку: Firebase Crashlytics, що відправляє стек помилок через network call, може бути розцінена як ексфільтрація даних; Google Play Integrity API, що перевіряє цілісність пристрою, може бути ідентифікований як підозрілий виклик. Для зниження хибних спрацьовувань необхідний період навчання (learning mode) тривалістю 7–14 днів, протягом якого RASP тільки логує, але не блокує.

Обхід RASP

Якщо атакуючий отримав kernel-level доступ (через експлойт ядра), RASP не може довіряти навіть власним перевіркам — агент працює в просторі користувача та бачить те, що йому дозволяє ядро. Для запобігання обходу на рівні ядра використовується Secure Boot Chain перевірка в комбінації з серверною атестацією. Крім того, RASP-агент сам повинен бути обфускований та захищений від налагодження — інакше атакуючий видалить або вимкне RASP до початку атаки.