RASP — nedir, çalışma prensibi ve gerçek zamanlı koruma

RASP nedir?

Runtime Application Self-Protection (RASP), derleme zamanında veya çalışma zamanı ajanı aracılığıyla uygulamaya entegre edilen bir güvenlik teknolojisidir. RASP, yürütme sırasında uygulamanın davranışını analiz eder ve bağlama göre saldırıları engelleme kararları alır: çağrının nereden geldiği, hangi verilerin iletildiği, yığının durumu nedir. İmza tabanlı sistemlerin aksine RASP bilinen saldırı modellerini aramaz — beklenen kod yürütme senaryosundan sapan anormal davranışı tespit eder.

RASP kavramı 2011 yılında Gartner tarafından resmileştirilmiş ve ilk ticari uygulamalar 2014–2015 yıllarında ortaya çıkmıştır. Mobil platformlar için RASP, 2017 yılında pazarın geleneksel karartmanın yetersizliğini fark etmesiyle aktif olarak kullanılmaya başlanmıştır. MarketsandMarkets (2025) raporuna göre RASP çözümleri pazarı 2,8 milyar USD büyüklüğünde olup yıllık büyüme oranı %24,5'tir. RASP uygulaması, ödeme verilerini işleyen uygulamalar için OWASP Mobile Top 10 ve PCI DSS 4.0 standartları tarafından önerilmektedir.

RASP iki düzeyde çalışır: engelleme ve değerlendirme. Engelleme, derleme zamanında veya dinamik enstrümantasyon yoluyla çalışma zamanında koda gömülen kancalar aracılığıyla sistem ve kitaplık çağrılarının yakalanmasıdır. Değerlendirme, çağrı bağlamının analizidir: giriş parametrelerinin, çağrı yığınının, sandbox durumunun, hata ayıklayıcı varlığının kontrolü. Karar, geliştirici tarafından belirlenen güvenlik politikasına göre verilir. Politika katı (engelle), yumuşak (günlükle) veya uyarlanabilir (tehdit seviyesine göre davranışı değiştir) olabilir.

RASP nasıl çalışır: mimari ve mekanizmalar

RASP ajanının mimarisi üç bileşenden oluşur: enstrümantasyon katmanı, analizör ve politika. Enstrümantasyon katmanı sistem çağrılarını ve framework çağrılarını yakalar. Analizör, bağlamı beklenen modellere göre kontrol eder. Politika yanıtı belirler.

Kod enstrümantasyonu

Mobil uygulamalar için derleme zamanı enstrümantasyonu kullanılır: bayt kodu veya yerel kod derleme sırasında değiştirilir — her tehlikeli çağrıdan önce bir kontrol eklenir. RASP ajanı derleyicisi, giriş noktaları FileOutputStream.write(), Runtime.exec(), Class.forName() ve android.app.Activity.onStart()'ı değiştirir. Android için Gradle eklentisi aracılığıyla DEX bayt kodu dönüşümü kullanılır; iOS için post-link betiği aracılığıyla Mach-O ikili dosyası değiştirilir.

Bağlam analizi

Bir çağrıyı yakalarken RASP şunları analiz eder: çağıran sınıf ve yöntem (kim çağırıyor), yığın izi (çağrı zinciri), argümanlar (iletilen veriler), dönüş değeri (ne döndürülüyor), zaman damgası ve iş parçacığı kimliği. Örneğin Runtime.exec() UI iş parçacığından ve uygulama kodundan değil de JNI aracılığıyla standart olmayan bir yoldan yüklenen bir kitaplıktan çağrıldığında bir anormallik kaydedilir. Veya FileOutputStream.write() beklenen PNG başlığı yerine yürütülebilir bayt kodu içeren veri aldığında.

Yanıt politikaları

RASP üç tür yanıtı destekler: Block — saldırı tespitinde uygulamayı zorla sonlandırma, Log — uygulamayı durdurmadan günlük toplama sunucusuna olay ayrıntılarını gönderme, Deceive — dönüş değerini sahte bir değerle değiştirerek saldırganın yanlış veri almasını sağlama. Log ve Deceive kombinasyonu, tespit gerçeğini ifşa etmeden saldırgan hakkında istihbarat toplamaya olanak tanır.

// Örnek: Runtime.exec() çağrısının RASP kontrolü
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // Çağıran kontrol ediliyor
        String caller = stack[1].getClassName();

        // Çağrı paketimizden değilse — şüpheli
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Komut kara listeye karşı kontrol ediliyor
        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: boş süreç
            }
        }

        return null; // yürütmeye izin ver
    }
}

RASP vs WAF ve diğer güvenlik araçları

RASP sıklıkla Web Application Firewall (WAF) ile karşılaştırılır, ancak temel fark konumlandırmadadır. WAF ağ çevresinde bulunur ve yalnızca HTTP isteklerini analiz eder. RASP uygulama içinde çalışır ve işleme mantığını görür.

Kodu okunamaz hale getiren karartmanın (ProGuard, DexGuard) aksine RASP, istismar sırasında saldırıları aktif olarak tespit eder. Karartma pasif korumadır: saldırgan tersine mühendisliğe yeterince zaman harcarsa kod okunacaktır. RASP aktiftir: saldırganın uygulamada hata ayıklamaya çalıştığını görür ve tek bir kod satırı okunmadan yanıt verir. Karartma + RASP kombinasyonu, karartmanın analizi yavaşlattığı ve RASP'nin enstrümantasyon aşamasında saldırıyı durdurduğu çok katmanlı koruma sağlar.

Mobil uygulamalarda RASP

Mobil RASP çözümleri Android ve iOS'un özelliklerine uyarlanmıştır. Sunucu tarafı Java uygulamalarının aksine, mobil RASP ajanları sınırlı bellek ve pil koşullarında çalışır ve hafif enstrümantasyon gerektirir.

Android'de RASP

Android'de RASP ajanı, derleme sırasında DEX bayt kodunu değiştiren bir Gradle eklentisi aracılığıyla gömülür. Ajan 50'den fazla sistem çağrısını yakalar, bunlar arasında: Runtime.exec() (su veya Frida yürütmesini tespit etmek için), Class.forName() (şüpheli sınıfların yüklenmesini belirlemek için), System.loadLibrary() (standart olmayan yollardan yerel kitaplıkların yüklenmesini kontrol etmek için). Ayrıca /proc/self/maps içinde frida-agent, frida-helper, libinject ve substrate kitaplıklarının varlığını kontrol eder.

iOS'ta RASP

iOS'ta RASP, Mach-O ikili dosyasının son işleme yoluyla uygulanır. Apple'ın ikili dosya değişikliği konusundaki katı gereksinimleri nedeniyle iOS daha karmaşıktır. Ajan fork(), dlopen(), ptrace() fonksiyon çağrılarını yakalar ve yüklenen kitaplıklar arasında CydiaSubstrate.dylib varlığını kontrol eder. iOS için RASP, App Store yapılarında kodu değiştiremez — yalnızca Enterprise dağıtımı içindir. App Store için Swift Macro veya Objective-C method swizzling aracılığıyla derleme zamanı enstrümantasyonu önerilir.

Analiz araçlarının tespiti

Mobil RASP şunları tespit eder: Frida (/proc/self/maps ve /data/local/tmp/frida* kontrolü yoluyla), Xposed Framework (ClassLoader'da de.robv.android.xposed.XposedBridge kontrolü yoluyla), JDWP hata ayıklayıcısı (Debug.isDebuggerConnected() yoluyla), emülatörler (Build.FINGERPRINT, Build.HARDWARE, Build.MODEL kontrolü yoluyla) ve AndroidManifest'teki debuggable bayrağı. NowSecure Mobile Threat Report (2025)'e göre bir RASP ajanı, enstrümante edilmiş Frida oturumlarının %89–97'sini tespit eder.

RASP ajanının pratik uygulaması

RASP'yi mobil bir uygulamaya entegre etmek, enstrümantasyonu yapılandırmayı, politikaları tanımlamayı ve olay günlüklerini toplamak için bir SIEM sistemiyle entegrasyonu gerektirir.

Uygulama seçimi: derleme zamanı vs çalışma zamanı

Derleme zamanı enstrümantasyonu — derleme sırasında bayt kodu değişikliği, çalışma zamanı performansını etkilemez. Çalışma zamanı enstrümantasyonu (sunucuda Java Agent veya istemcide Frida aracılığıyla) daha esnektir ancak %5–10 ek yük getirir. Mobil uygulamalar için derleme zamanı yaklaşımı önerilir çünkü sürekli ağ bağlantısı gerektirmez ve analiz için pil tüketmez.

Mevcut kitaplıklarla entegrasyon

RASP ajanı popüler SDK'larla doğru şekilde çalışmalıdır. Firebase Crashlytics, Google Analytics ve Appsee engellenmemelidir. Bilinen kitaplıklar için beyaz liste yapılandırması zorunludur. Ajan yapılandırmasında istisnalar belirtilir: çağrı com.google.firebase sınıfından geliyorsa — kontrol atlanır. Beyaz liste her SDK sürümüyle güncellenir.

Olay işleme örneği

RASP ajanı aracılığıyla Frida tespit edildiğinde şunlar olur: bağlam toplama (yığın izi, işletim sistemi sürümü, saat), şifrelenmiş biçimde günlük sunucusuna veri gönderme, politikanın yürütülmesi (çökme, yalnızca günlük veya deceive), toplu saldırıyı belirlemek için bir sayacın artırılması. Farklı cihazlardan gelen veriler, saldırı modellerini belirlemek için sunucuda toplanır.

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)
            }
        }
    }
}

Sınırlamalar ve yanlış pozitifler

RASP gümüş bir kurşun değildir. Teknolojinin koruma tasarlanırken dikkate alınması gereken sınırlamaları vardır.

Performans

Yakalanan her çağrı bağlam kontrolü ekler. Agresif yapılandırmada (tüm IO ve exec çağrılarını yakalama) performans %5–15 düşebilir. Mobil uygulamalar için başlangıç süresi kritiktir: RASP başlatma, başlangıçta 200–500 ms ekler. Hedeflenmiş enstrümantasyon önerilir — tüm olası fonksiyonlar değil, yalnızca kritik fonksiyonlar. Test sırasında RASP ajanıyla profil oluşturma zorunludur.

Yanlış pozitifler

RASP meşru davranışı engelleyebilir: Firebase Crashlytics'in bir ağ çağrısı aracılığıyla hata yığını göndermesi veri sızıntısı olarak yanlış yorumlanabilir; Google Play Integrity API'nin cihaz bütünlüğünü kontrol etmesi şüpheli bir çağrı olarak tanımlanabilir. Yanlış pozitifleri azaltmak için, RASP'nin yalnızca günlük tuttuğu ancak engellemediği 7–14 günlük bir öğrenme modu süresi gereklidir.

RASP'yi atlatma

Saldırgan çekirdek düzeyinde erişim elde ederse (bir çekirdek istismarı yoluyla), RASP kendi kontrollerine bile güvenemez — ajan kullanıcı alanında çalışır ve yalnızca çekirdeğin görmesine izin verdiği şeyleri görür. Çekirdek düzeyinde atlatmayı önlemek için sunucu tarafı onaylama ile birlikte Secure Boot Chain kontrolü kullanılır. Ayrıca RASP ajanının kendisi karartılmış ve hata ayıklamaya karşı korunmuş olmalıdır — aksi takdirde saldırgan saldırıyı başlatmadan önce RASP'yi kaldıracak veya devre dışı bırakacaktır.