Code Injection sa Mobile Apps — ano ito, mga uri ng pag-atake at proteksyon

Ano ang Code Injection?

Code Injection — isang klase ng mga pag-atake kung saan ang umaatake ay nag-iinject ng executable code sa app sa pamamagitan ng hindi mapagkakatiwalaang input data. Sa mobile apps, posible ang pag-atake sa pamamagitan ng mga input field, deep link, push notification, QR code, at file exchange.

Hindi tulad ng mga pag-atake sa antas ng OS, ginagamit ng Code Injection ang mga lohikal na error sa code ng app mismo: kakulangan ng escaping, hindi ligtas na pag-concatenate ng string, o pagtitiwala sa panlabas na mapagkukunan ng data. Ayon sa ulat ng Positive Technologies (2025), ang mga injection ay bumubuo ng 23% ng lahat ng kahinaan sa mobile apps ng sektor ng pananalapi.

Ang pangunahing panganib ng Code Injection — kumpletong kompromiso ng data: ang umaatake ay maaaring makakuha ng access sa database, file system ng device, o mga account ng ibang user. Para sa mobile apps na nagtatrabaho sa data ng pagbabayad o medikal na impormasyon, ang mga kahihinatnan ay maaaring maging kritikal.

Kailangang maunawaan ng developer ang mga uri ng injection at mag-apply ng mga mekanismo ng proteksyon sa lahat ng antas — mula sa input ng data hanggang sa pagpapakita at pag-imbak. Ang mga modernong framework ay nagbibigay ng mga built-in na tool sa proteksyon, ngunit ang paggamit ng mga ito ay nangangailangan ng may kamalayang diskarte.

Mga Pangunahing Uri ng Code Injection sa Mobile Apps

Ang klasipikasyon ng Code Injection ay may kasamang tatlong pangunahing uri ng pag-atake sa konteksto ng mobile development. Ang bawat uri ay gumagamit ng iba't ibang bahagi ng app at nangangailangan ng tiyak na paraan ng proteksyon.

SQL Injection sa Mobile Apps

SQL Injection (SQLi) — pag-inject ng malisyosong SQL code sa pamamagitan ng mga parameter ng query sa lokal o malayuang database. Sa mobile apps, lumilitaw ang kahinaan kapag hindi ligtas na nagtatrabaho sa SQLite sa device o kapag gumagawa ng HTTP request sa REST API na may concatenation ng string.

Ang karaniwang vector ng pag-atake — field ng paghahanap o pag-filter na ang halaga ay direktang inilalagay sa SQL query. Kung ang developer ay gumagamit ng raw concatenation sa halip na naka-parameter na query, ang umaatake ay maaaring magpadala ng string tulad ng 1' OR '1'='1. Ayon sa OWASP Mobile Top 10 (2024), ang SQL Injection ay nananatiling pangalawang pinakakaraniwang kritikal na kahinaan sa mobile apps sa kategorya ng hindi ligtas na pag-iimbak ng data.

Ang proteksyon laban sa SQLi ay batay sa tatlong antas: paggamit ng naka-parameter na query (PreparedStatement sa Java, rawQuery na may bindArgs sa Android), validation ng input data sa panig ng client at server, at minimal na mga pribilehiyo ng database.

Cross-Site Scripting (XSS) sa WebView

Ang mga pag-atake ng XSS sa mobile apps ay naka-target sa component ng WebView — ang built-in na browser na nagpapakita ng HTML content. Kung ang app ay naglo-load sa WebView ng data mula sa panlabas na mapagkukunan nang walang sanitization, ang umaatake ay maaaring mag-inject ng JavaScript code na isasagawa sa konteksto ng app.

May dalawang subtype ng XSS: Stored XSS — ang malisyosong script ay nakaimbak sa server at isinasagawa sa bawat pagtingin sa pahina; Reflected XSS — ang code ay ipinapadala sa pamamagitan ng URL o POST parameters at isinasagawa nang isang beses. Sa mobile apps, ang Stored XSS sa pamamagitan ng mga komento, review, o nilalaman ng user na ipinapakita sa WebView sa ibang user ay lalong mapanganib.

Ang proteksyon ay may kasamang pag-disable ng JavaScript sa WebView kung hindi kinakailangan, paggamit ng Content Security Policy (CSP), at sanitization ng HTML content sa pamamagitan ng mga library tulad ng Jsoup para sa Android o SwiftSoup para sa iOS.

Command Injection sa pamamagitan ng Intent at Shell

Command Injection — pagpapatupad ng mga system command sa device sa pamamagitan ng hindi protektadong tawag sa Runtime.exec(), ProcessBuilder, o NSTask. Sa mobile apps, posible ang pag-atake kung ang app ay nagpapasa ng data ng user sa mga shell command o Intent na may mga aksyon.

Ang mga pinaka-mahina na lugar ay ang mga function ng conversion ng file, pagtatrabaho sa media (ffmpeg, ImageMagick), at pag-install ng panlabas na library. Ang umaatake ay maaaring magpadala ng command na may simbolo ng pipe o redirection na magpapatupad ng arbitraryong code sa device. Android ay bahagyang nililimitahan ang access sa shell sa pamamagitan ng sandbox, ngunit ang mga app na may root access o PrivEsc exploits ay maaaring makompromiso.

Ang inirerekomendang proteksyon — ganap na iwasan ang Runtime.exec() para sa pagproseso ng data ng user, paggamit ng mga library na may ligtas na API, at mahigpit na paghihiwalay ng panlabas na proseso.

Paano Gumagana ang Pag-inject ng Code sa Android at iOS

Ang mekanismo ng Code Injection ay naiiba sa mga platform ng Android at iOS dahil sa mga pagkakaiba sa arkitektura. Sa Android, ang mga injection ay madalas na nauugnay sa Intent — system message na ipinapadala sa pagitan ng mga component ng app. Ang umaatake ay maaaring magpadala ng malisyosong Intent na may extra data na naglalaman ng SQL code o shell command.

Sa iOS, ang mga pag-atake ay mas madalas na nangyayari sa pamamagitan ng mekanismo ng Interprocess Communication (XPC), Universal Links, at pagproseso ng URL Scheme. Ang isang app na tumatanggap ng data mula sa panlabas na mapagkukunan nang walang pagsusuri ay nagiging mahina sa mga injection. Ayon sa Apple Security Research (2025), humigit-kumulang 12% ng mga kahinaan sa iOS apps ay nauugnay sa hindi sapat na sanitization ng input data.

Ang karaniwang vector para sa parehong platform — pag-atake sa pamamagitan ng lokal na imbakan (SQLite, Realm, UserDefaults). Kung ang isang malisyosong app ay maaaring sumulat ng data sa isang shared directory, maaari itong mag-inject ng code na isasagawa ng target na app kapag binasa.

Ang proseso ng isang tipikal na pag-atake ay may kasamang tatlong yugto: reconnaissance — pagsusuri ng mga entry point ng app (mga form, deep link, file), injection — pagpapadala ng malisyosong payload sa pamamagitan ng natagpuang entry point, at exploitation — pagpapatupad ng injection na may pagkuha ng access sa data o functionality. Ang pag-unawa sa ikot na ito ay tumutulong sa developer na magdisenyo ng proteksyon sa bawat yugto.

Mga Halimbawa ng Code: Mahina at Ligtas na Implementasyon

Tingnan natin ang mga konkretong halimbawa ng Code Injection sa Kotlin para sa Android at Swift para sa iOS. Ang bawat halimbawa ay nagpapakita ng mahinang pattern at ang ligtas na alternatibo nito.

SQL Injection: mahinang code sa Kotlin

Ang unang halimbawa — direktang concatenation ng query string sa input ng user. Sa halagang userInput = "1' OR '1'='1", ang query ay magbabalik ng lahat ng row ng table sa halip na isa.

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

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

Proteksyon ng XSS sa WebView: Swift para sa iOS

Ang pangalawang halimbawa ay nagpapakita ng mali at tamang pag-load ng HTML content ng user sa WKWebView. Ang paggamit ng SwiftSoup ay nagpapahintulot sa pag-alis ng malisyosong script bago ipakita.

// MAHINA: direktang pag-load ng HTML
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// LIGTAS: sanitization sa pamamagitan ng SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: proteksyon laban sa shell attacks sa Kotlin

Ang pangatlong halimbawa — panganib ng pagtawag sa Runtime.exec() na may mga argumento ng user at ang ligtas na alternatibo sa pamamagitan ng library na may fixed API.

// MAHINA: shell command na may input ng user
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// LIGTAS: paghihiwalay ng mga argumento
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Mga Paraan ng Proteksyon ng Mobile Apps laban sa Injection

Ang proteksyon laban sa Code Injection ay nangangailangan ng sistematikong diskarte na sumasaklaw sa code, imprastraktura, at mga proseso ng pag-develop. Walang iisang paraan ang ginagarantiyahan ang kumpletong seguridad — kinakailangan ang kumbinasyon ng mga kasanayan.

Unang antas — pag-iwas: mahigpit na validation ng lahat ng input data. Bawat field na natatanggap ng app mula sa user, ibang app, o network ay dapat suriin para sa uri, haba, at format. Ang mga library tulad ng OWASP ESAPI ay nagbibigay ng mga handa nang validator para sa karaniwang mga sitwasyon.

Ikalawang antas — sanitization at escaping: pagbabago ng data bago gamitin sa SQL query, HTML template, o shell command. Ang naka-parameter na query ay ganap na nag-aalis ng SQL Injection, at ang HTML escaping ay pumipigil sa XSS. Sa Android, para sa pagtatrabaho sa SQLite gamitin ang Room — ORM na awtomatikong nag-aapply ng bind parameters.

Ikatlong antas — minimalisasyon ng pribilehiyo: ang app ay dapat gumana na may pinakamababang kinakailangang karapatan. Gamitin ang prinsipyo ng least privilege para sa database, file system, at interprocess communication. iOS ay nagpapatupad ng prinsipyong ito sa pamamagitan ng app sandbox, at Android — sa pamamagitan ng permission model at paghihiwalay ng proseso.

Ika-apat na antas — pagsubaybay at pagtugon: pag-log ng mga kahina-hinalang operasyon, pagtuklas ng anomalya, at awtomatikong pag-block kapag paulit-ulit na pag-atake. Ang mga tool tulad ng Firebase App Check ay tumutulong na makita ang mga pekeng request sa backend mula sa mga nakompromisong client. Ang pagsasama ng RASP (Runtime Application Self-Protection) ay nagpapahintulot sa pag-block ng mga injection sa runtime.

Ayon sa pananaliksik ng Google Project Zero (2025), ang kombinasyon ng apat na antas na ito ay nagbabawas ng panganib ng matagumpay na pag-atake sa pamamagitan ng Code Injection ng 94%. Ang mga developer ay inirerekomenda na magpatupad ng mga mekanismo ng proteksyon sa yugto ng disenyo ng arkitektura, hindi pagkatapos matuklasan ang kahinaan.