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 агента састоји се од три компоненте: слоја инструментације, анализатора и политике. Слој инструментације пресреће системске позиве и позиве оквира. Анализатор проверава контекст у односу на очекиване обрасце. Политика одређује реакцију.

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

За мобилне апликације користи се инструментација у време компилације (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-у. Инструментација у 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 не може да верује чак ни сопственим проверама — агент ради у простору корисника и види оно што му кернел дозвољава. За спречавање заобилажења на нивоу кернела користи се проверa Secure Boot Chain у комбинацији са серверском атестацијом. Поред тога, сам RASP агент мора бити обфускован и заштићен од отклањања грешака — иначе ће нападач уклонити или онемогућити RASP пре почетка напада.