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 — прихващане на системни и библиотечни извиквания чрез куки, вградени в кода на етапа на изграждане или по време на изпълнение чрез динамична инструментация. Assessment — анализ на контекста на извикване: проверка на входните параметри, стека на извикванията, състоянието на 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 анализира: класа и метода на извикващия (кой извиква), проследяване на стека (верига от извиквания), аргументите (предавани данни), върнатата стойност (какво се връща), времевия печат и 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) {

        // Проверка на извикващия
        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 активно открива атаки по време на експлоатация. Обфускацията е пасивна защита: ако атакуващият отдели достатъчно време за обратно инженерство, кодът ще бъде прочетен. 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 се препоръчва използването на инструментация по време на компилация чрез 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) (чрез Java Agent на сървъра или Frida на клиента) — по-гъвкава, но добавя 5–10% допълнително натоварване. За мобилни приложения се препоръчва compile-time подходът, тъй като не изисква постоянна мрежова връзка и не изразходва батерия за анализ.

Интеграция със съществуващи библиотеки

RASP агентът трябва да работи коректно с популярни SDK. Firebase Crashlytics, Google Analytics и Appsee не трябва да бъдат блокирани. Конфигурирането на whitelist за известни библиотеки е задължително. В конфигурацията на агента се задават изключения: ако извикването идва от клас com.google.firebase — проверката се пропуска. Whitelist се актуализира с всяка версия на SDK.

Пример за обработка на инцидент

При откриване на Frida от RASP агента се извършва: събиране на контекст (проследяване на стек, версия на ОС, време), изпращане на данни до сървъра за логване в криптиран вид, изпълнение на политиката (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 ms при стартиране. Препоръчва се точкова инструментация — само критични функции, а не всички възможни. Профилирането с RASP агент е задължително на етапа на тестване.

Фалшиви аларми

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

Заобикаляне на RASP

Ако атакуващият получи достъп на ниво ядро (чрез експлойт на ядрото), RASP не може да вярва дори на собствените си проверки — агентът работи в потребителското пространство и вижда това, което ядрото му позволява. За предотвратяване на заобикаляне на ниво ядро се използва проверка на Secure Boot Chain в комбинация с сървърна атестация. Освен това, самият RASP агент трябва да бъде обфусциран и защитен от дебъгване — иначе атакуващият ще премахне или деактивира RASP преди началото на атаката.