Code Injection di Aplikasi Mobile — apa itu, jenis serangan dan perlindungan

Apa itu Code Injection?

Code Injection — kelas serangan di mana penyerang menyuntikkan kode yang dapat dieksekusi ke dalam aplikasi melalui data masukan yang tidak tepercaya. Dalam aplikasi mobile, serangan mungkin terjadi melalui bidang input, deep link, notifikasi push, kode QR, dan pertukaran file.

Tidak seperti serangan tingkat sistem operasi, Code Injection mengeksploitasi kesalahan logis dalam kode aplikasi itu sendiri: kurangnya escaping, konkatenasi string yang tidak aman, atau kepercayaan pada sumber data eksternal. Menurut laporan Positive Technologies (2025), injeksi merupakan 23% dari semua kerentanan dalam aplikasi mobile sektor keuangan.

Bahaya utama Code Injection — kompromi data total: penyerang dapat memperoleh akses ke basis data, sistem file perangkat, atau akun pengguna lain. Untuk aplikasi mobile yang bekerja dengan data pembayaran atau informasi medis, konsekuensinya bisa kritis.

Pengembang harus memahami jenis injeksi dan menerapkan mekanisme perlindungan di semua tingkatan — dari input data hingga tampilan dan penyimpanan. Framework modern menyediakan alat perlindungan bawaan, tetapi penggunaannya memerlukan pendekatan yang sadar.

Jenis Utama Code Injection di Aplikasi Mobile

Klasifikasi Code Injection mencakup tiga jenis serangan utama dalam konteks pengembangan mobile. Setiap jenis mengeksploitasi komponen aplikasi yang berbeda dan memerlukan metode perlindungan spesifik.

SQL Injection di Aplikasi Mobile

SQL Injection (SQLi) — injeksi kode SQL berbahaya melalui parameter kueri ke basis data lokal atau jarak jauh. Dalam aplikasi mobile, kerentanan muncul saat bekerja tidak aman dengan SQLite di perangkat atau saat membangun permintaan HTTP ke REST API dengan konkatenasi string.

Vektor serangan khas — bidang pencarian atau pemfilteran yang nilainya dimasukkan langsung ke dalam kueri SQL. Jika pengembang menggunakan konkatenasi mentah alih-alih kueri terparameter, penyerang dapat mengirimkan string seperti 1' OR '1'='1. Menurut OWASP Mobile Top 10 (2024), SQL Injection tetap menjadi kerentanan kritis kedua paling umum dalam aplikasi mobile dalam kategori penyimpanan data yang tidak aman.

Perlindungan terhadap SQLi didasarkan pada tiga tingkat: penggunaan kueri terparameter (PreparedStatement di Java, rawQuery dengan bindArgs di Android), validasi data masukan di sisi klien dan server, serta hak istimewa basis data minimal.

Cross-Site Scripting (XSS) di WebView

Serangan XSS dalam aplikasi mobile menargetkan komponen WebView — peramban bawaan yang menampilkan konten HTML. Jika aplikasi memuat data dari sumber eksternal ke WebView tanpa sanitasi, penyerang dapat menyuntikkan kode JavaScript yang akan dijalankan dalam konteks aplikasi.

Ada dua subtipe XSS: Stored XSS — skrip berbahaya disimpan di server dan dijalankan setiap kali halaman dilihat; Reflected XSS — kode dikirimkan melalui URL atau parameter POST dan dijalankan sekali. Dalam aplikasi mobile, Stored XSS melalui komentar, ulasan, atau konten pengguna yang ditampilkan di WebView kepada pengguna lain sangat berbahaya.

Perlindungan mencakup menonaktifkan JavaScript di WebView jika tidak diperlukan, menggunakan Content Security Policy (CSP), dan sanitasi konten HTML melalui pustaka seperti Jsoup untuk Android atau SwiftSoup untuk iOS.

Command Injection melalui Intent dan Shell

Command Injection — eksekusi perintah sistem pada perangkat melalui panggilan Runtime.exec(), ProcessBuilder, atau NSTask yang tidak aman. Dalam aplikasi mobile, serangan mungkin terjadi jika aplikasi meneruskan data pengguna ke perintah shell atau Intent dengan tindakan.

Tempat paling rentan adalah fungsi konversi file, bekerja dengan media (ffmpeg, ImageMagick), dan instalasi pustaka eksternal. Penyerang dapat mengirimkan perintah dengan simbol pipa atau pengalihan yang akan mengeksekusi kode sembarang pada perangkat. Android sebagian membatasi akses shell melalui sandbox, tetapi aplikasi dengan akses root atau eksploitasi PrivEsc dapat dikompromikan.

Perlindungan yang direkomendasikan — sepenuhnya menghindari Runtime.exec() untuk memproses data pengguna, menggunakan pustaka dengan API aman, dan isolasi ketat proses eksternal.

Bagaimana Injeksi Kode Bekerja di Android dan iOS

Mekanisme Code Injection berbeda pada platform Android dan iOS karena perbedaan arsitektur. Di Android, injeksi sering terkait dengan Intent — pesan sistem yang dikirimkan antar komponen aplikasi. Penyerang dapat mengirim Intent berbahaya dengan data ekstra yang berisi kode SQL atau perintah shell.

Di iOS, serangan lebih sering terjadi melalui mekanisme Interprocess Communication (XPC), Universal Links, dan pemrosesan URL Scheme. Aplikasi yang menerima data dari sumber eksternal tanpa pemeriksaan menjadi rentan terhadap injeksi. Menurut Apple Security Research (2025), sekitar 12% kerentanan dalam aplikasi iOS terkait dengan sanitasi data masukan yang tidak memadai.

Vektor umum untuk kedua platform — serangan melalui penyimpanan lokal (SQLite, Realm, UserDefaults). Jika aplikasi berbahaya dapat menulis data ke direktori bersama, ia dapat menyuntikkan kode yang akan dieksekusi oleh aplikasi target saat dibaca.

Proses serangan tipikal mencakup tiga tahap: pengintaian — analisis titik masuk aplikasi (formulir, deep link, file), injeksi — pengiriman muatan berbahaya melalui titik masuk yang ditemukan, dan eksploitasi — eksekusi injeksi dengan memperoleh akses ke data atau fungsionalitas. Memahami siklus ini membantu pengembang merancang perlindungan di setiap tahap.

Contoh Kode: Implementasi Rentan dan Aman

Mari kita lihat contoh konkret Code Injection di Kotlin untuk Android dan Swift untuk iOS. Setiap contoh menunjukkan pola rentan dan alternatif amannya.

SQL Injection: kode rentan di Kotlin

Contoh pertama — konkatenasi langsung string kueri dengan masukan pengguna. Pada nilai userInput = "1' OR '1'='1", kueri akan mengembalikan semua baris tabel alih-alih satu.

// RENTAN: konkatenasi string
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

// AMAN: kueri terparameter
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

Perlindungan XSS di WebView: Swift untuk iOS

Contoh kedua menunjukkan pemuatan konten HTML pengguna yang salah dan benar di WKWebView. Penggunaan SwiftSoup memungkinkan penghapusan skrip berbahaya sebelum ditampilkan.

// RENTAN: pemuatan HTML langsung
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// AMAN: sanitasi melalui SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: perlindungan dari serangan shell di Kotlin

Contoh ketiga — bahaya pemanggilan Runtime.exec() dengan argumen pengguna dan alternatif aman melalui pustaka dengan API tetap.

// RENTAN: perintah shell dengan input pengguna
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// AMAN: isolasi argumen
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Metode Perlindungan Aplikasi Mobile dari Injeksi

Perlindungan terhadap Code Injection memerlukan pendekatan sistematis yang mencakup kode, infrastruktur, dan proses pengembangan. Tidak ada satu metode pun yang menjamin keamanan penuh — kombinasi praktik diperlukan.

Tingkat pertama — pencegahan: validasi ketat semua data masukan. Setiap bidang yang diterima aplikasi dari pengguna, aplikasi lain, atau jaringan harus diperiksa jenis, panjang, dan formatnya. Pustaka seperti OWASP ESAPI menyediakan validator siap pakai untuk skenario umum.

Tingkat kedua — sanitasi dan escaping: transformasi data sebelum digunakan dalam kueri SQL, template HTML, atau perintah shell. Kueri terparameter sepenuhnya menghilangkan SQL Injection, dan escaping HTML mencegah XSS. Di Android, untuk bekerja dengan SQLite gunakan Room — ORM yang secara otomatis menerapkan parameter bind.

Tingkat ketiga — minimalisasi hak istimewa: aplikasi harus beroperasi dengan hak minimal yang diperlukan. Terapkan prinsip hak istimewa paling rendah untuk basis data, sistem file, dan komunikasi antarproses. iOS menerapkan prinsip ini melalui sandbox aplikasi, dan Android melalui model izin dan isolasi proses.

Tingkat keempat — pemantauan dan respons: pencatatan operasi mencurigakan, deteksi anomali, dan pemblokiran otomatis saat serangan berulang. Alat seperti Firebase App Check membantu mendeteksi permintaan palsu ke backend dari klien yang dikompromikan. Integrasi RASP (Runtime Application Self-Protection) memungkinkan pemblokiran injeksi saat runtime.

Menurut penelitian Google Project Zero (2025), kombinasi keempat tingkat ini mengurangi risiko serangan berhasil melalui Code Injection sebesar 94%. Pengembang disarankan untuk menerapkan mekanisme perlindungan pada tahap desain arsitektur, bukan setelah menemukan kerentanan.