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 работает на двух уровнях: interception и assessment. Interception — перехват системных и библиотечных вызовов через хуки, встраиваемые в код на этапе сборки или в runtime через динамическую инструментацию. Assessment — анализ контекста вызова: проверка входных параметров, стека вызовов, состояния sandbox, наличия отладчика. Решение принимается на основе политики безопасности, задаваемой разработчиком. Политика может быть жёсткой (блокировать), мягкой (логировать) или адаптивной (изменять поведение в зависимости от уровня угрозы).

Как работает RASP: архитектура и механизмы

Архитектура RASP-агента состоит из трёх компонентов: instrumentation layer, анализатор и политика. Instrumentation layer перехватывает системные вызовы и вызовы фреймворка. Анализатор проверяет контекст на соответствие ожидаемым паттернам. Политика определяет реакцию.

Инструментация кода

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

Анализ контекста

При перехвате вызова RASP анализирует: caller class и method (кто вызывает), 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 instrumentation через 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 в мобильное приложение требует настройки instrumentation, определения политик и интеграции с SIEM-системой для сбора логов инцидентов.

Выбор реализации: compile-time vs runtime

Compile-time instrumentation — модификация байткода на этапе сборки, не влияющая на производительность в runtime. Runtime instrumentation (через 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 до начала атаки.