Code Injection у мобилним апликацијама — шта је то, врсте напада и заштита

Шта је Code Injection?

Code Injection — класа напада у којима нападач убризгава извршни кôд у апликацију кроз неповерљиве улазне податке. У мобилним апликацијама напад је могућ кроз поља за унос, deep link-ове, push обавештења, QR кодове и размену датотека.

За разлику од напада на нивоу оперативног система, Code Injection искоришћава логичке грешке у коду саме апликације: недостатак екранизације, небезбедну конкатенацију стрингова или поверење у спољне изворе података. Према извештају Positive Technologies (2025), инјекције чине 23% свих рањивости у мобилним апликацијама финансијског сектора.

Главна опасност Code Injection — потпуна компромитација података: нападач може добити приступ бази података, систему датотека уређаја или налозима других корисника. За мобилне апликације које раде са подацима о плаћању или медицинским информацијама последице могу бити критичне.

Програмер треба да разуме врсте инјекција и примењује заштитне механизме на свим нивоима — од уноса података до њиховог приказа и складиштења. Савремени оквири пружају уграђена средства заштите, али њихово коришћење захтева свестан приступ.

Главне врсте Code Injection у мобилним апликацијама

Класификација Code Injection укључује три главне врсте напада у контексту мобилног развоја. Свака врста искоришћава различите компоненте апликације и захтева специфичне методе заштите.

SQL Injection у мобилним апликацијама

SQL Injection (SQLi) — убризгавање злонамерног SQL кода кроз параметре упита ка локалној или удаљеној бази података. У мобилним апликацијама рањивост настаје при небезбедном раду са SQLite на уређају или при конструисању HTTP захтева ка REST API уз конкатенацију стрингова.

Типичан вектор напада — поље за претрагу или филтрирање чија вредност се директно умеће у SQL упит. Ако програмер користи сирову конкатенацију уместо параметризованих упита, нападач може послати стринг попут 1' OR '1'='1. Према OWASP Mobile Top 10 (2024), SQL Injection остаје друга најчешћа критична рањивост у мобилним апликацијама у категорији небезбедног складиштења података.

Заштита од SQLi се заснива на три нивоа: коришћење параметризованих упита (PreparedStatement у Java, rawQuery са bindArgs у Android), валидација улазних података на страни клијента и сервера и минималне привилегије базе података.

Cross-Site Scripting (XSS) у WebView

XSS напади у мобилним апликацијама усмерени су на компоненту WebView — уграђени прегледач који приказује HTML садржај. Ако апликација учитава у WebView податке из спољних извора без санитизације, нападач може убризгати JavaScript кôд који ће се извршити у контексту апликације.

Разликују се два подтипа XSS: Stored XSS — злонамерни скрипт се чува на серверу и извршава при сваком приказу странице; Reflected XSS — кôд се преноси кроз URL или POST параметре и извршава се једнократно. У мобилним апликацијама посебно је опасан Stored XSS кроз коментаре, рецензије или кориснички садржај који се приказује у WebView другим корисницима.

Заштита укључује искључивање JavaScript у WebView ако није потребан, коришћење Content Security Policy (CSP) и санитизацију HTML садржаја кроз библиотеке попут Jsoup за Android или SwiftSoup за iOS.

Command Injection кроз Intent и Shell

Command Injection — извршавање системских команди на уређају кроз небезбедне позиве Runtime.exec(), ProcessBuilder или NSTask. У мобилним апликацијама напад је могућ ако апликација прослеђује корисничке податке shell командама или Intent-има са акцијама.

Најрањивија места су функције конверзије датотека, рада са медијима (ffmpeg, ImageMagick) и инсталације спољних библиотека. Нападач може послати команду са симболом цевовода или преусмеравања која ће извршити произвољни кôд на уређају. Android делимично ограничава shell приступ кроз пешчаник (sandbox), али апликације са root приступом или PrivEsc експлоитима могу бити компромитоване.

Препоручена заштита — потпуно одбацивање Runtime.exec() за обраду корисничких података, коришћење библиотека са безбедним API-јем и строга изолација спољних процеса.

Како функционише убризгавање кода на Android и iOS

Механизам Code Injection се разликује на платформама Android и iOS због архитектуралних разлика. На Android инјекције су често повезане са Intent — системском поруком која се преноси између компоненти апликације. Нападач може послати злонамерни Intent са extra подацима који садрже SQL кôд или shell команде.

На iOS напади се чешће дешавају кроз механизам Interprocess Communication (XPC), Universal Links и обраду URL Scheme. Апликација која прима податке из спољних извора без провере постаје рањива на инјекције. Према Apple Security Research (2025), око 12% рањивости у iOS апликацијама повезано је са недовољном санитизацијом улазних података.

Заједнички вектор за обе платформе — напад кроз локално складиште (SQLite, Realm, UserDefaults). Ако злонамерна апликација може да упише податке у заједнички директоријум, може убризгати кôд који ће бити извршен од стране циљне апликације при читању.

Процес типичног напада укључује три фазе: извиђање — анализа улазних тачака апликације (формулари, deep link-ови, датотеке), инјекција — пренос злонамерног терета кроз пронађену улазну тачку и експлоатација — извршење инјекције са добијањем приступа подацима или функционалности. Разумевање овог циклуса помаже програмеру да пројектује заштиту на свакој фази.

Примери кода: рањиве и безбедне имплементације

Размотримо конкретне примере Code Injection у Kotlin за Android и Swift за iOS. Сваки пример приказује рањиви образац и његову безбедну алтернативу.

SQL Injection: рањиви кôд у Kotlin

Први пример — директна конкатенација стринга упита са корисничким уносом. При вредности userInput = "1' OR '1'='1" упит ће вратити све редове табеле уместо једног.

// РАЊИВО: конкатенација стрингова
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

// БЕЗБЕДНО: параметризовани упит
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

XSS заштита у WebView: Swift за iOS

Други пример демонстрира неправилно и правилно учитавање корисничког HTML садржаја у WKWebView. Коришћење SwiftSoup омогућава уклањање злонамерних скрипти пре приказа.

// РАЊИВО: директно учитавање HTML-а
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// БЕЗБЕДНО: санитизација кроз SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: заштита од shell напада на Kotlin

Трећи пример — опасност позива Runtime.exec() са корисничким аргументима и безбедна алтернатива кроз библиотеку са фиксним API-јем.

// РАЊИВО: shell команда са корисничким уносом
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// БЕЗБЕДНО: изолација аргумената
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Методе заштите мобилних апликација од инјекција

Заштита од Code Injection захтева систематски приступ који обухвата кôд, инфраструктуру и развојне процесе. Ниједна појединачна метода не гарантује потпуну безбедност — неопходна је комбинација пракси.

Први ниво — превенција: строга валидација свих улазних података. Свако поље које апликација прима од корисника, друге апликације или мреже мора бити проверено на тип, дужину и формат. Библиотеке попут OWASP ESAPI пружају готове валидаторе за уобичајене сценарије.

Други ниво — санитизација и екранизација: трансформација података пре њиховог коришћења у SQL упитима, HTML шаблонима или shell командама. Параметризовани упити потпуно елиминишу SQL Injection, а HTML екранизација спречава XSS. На Android за рад са SQLite користите Room — ORM који аутоматски примењује bind параметре.

Трећи ниво — минимизација привилегија: апликација треба да ради са минимално потребним правима. Користите принцип најмање привилегије за базу података, систем датотека и међупроцесну комуникацију. iOS имплементира овај принцип кроз пешчаник апликација, а Android — кроз модел дозвола и изолацију процеса.

Четврти ниво — мониторинг и реаговање: евидентирање сумњивих операција, откривање аномалија и аутоматско блокирање при понављању напада. Алати попут Firebase App Check помажу у откривању лажних захтева ка бекенду од компромитованих клијената. Интеграција RASP (Runtime Application Self-Protection) омогућава блокирање инјекција у реалном времену.

Према истраживању Google Project Zero (2025), комбинација ова четири нивоа смањује ризик успешног напада путем Code Injection за 94%. Програмерима се препоручује имплементација заштитних механизама у фази пројектовања архитектуре, а не након откривања рањивости.