Code Injection (kod inyeksiyası) — hücum edən şəxsin tətbiqin giriş məlumatları vasitəsilə zərərli kodu ötürərək icazəsiz əməliyyatlar həyata keçirdiyi hücum növüdür. OWASP, 2024 məlumatlarına görə, inyeksiyalar ən kritik zəifliklər arasında ilk üçlükdədir. Kod inyeksiyası mexanizmlərini başa düşmək tərtibatçılara ilk gündən təhlükəsiz sistemlər layihələndirməyə imkan verir.
Əsas məqamlar
Code Injection — hücum edən şəxsin etibarsız giriş məlumatları vasitəsilə tətbiqə icra olunan kod daxil etdiyi hücum sinfidir. Mobil tətbiqlərdə hücum giriş sahələri, deep link-lər, push bildirişləri, QR kodları və fayl mübadiləsi vasitəsilə mümkündür.
Əməliyyat sistemi səviyyəsindəki hücumlardan fərqli olaraq, Code Injection tətbiqin öz kodundakı məntiqi səhvlərdən istifadə edir: ekranlaşdırmanın olmaması, təhlükəsiz olmayan sətir birləşdirilməsi və ya xarici məlumat mənbələrinə etibar. Positive Technologies (2025) hesabatına görə, inyeksiyalar maliyyə sektorunun mobil tətbiqlərindəki bütün zəifliklərin 23%-ni təşkil edir.
Code Injection-in əsas təhlükəsi — məlumatların tam kompromatasiyası: hücum edən şəxs verilənlər bazasına, cihazın fayl sisteminə və ya digər istifadəçilərin hesablarına giriş əldə edə bilər. Ödəniş məlumatları və ya tibbi məlumatlarla işləyən mobil tətbiqlər üçün nəticələr kritik ola bilər.
Tərtibatçı inyeksiya növlərini başa düşməli və bütün səviyyələrdə — məlumat daxil edilməsindən onların göstərilməsi və saxlanmasına qədər qoruyucu mexanizmlər tətbiq etməlidir. Müasir freymvorklar daxili qoruma vasitələri təqdim edir, lakin onların istifadəsi şüurlu yanaşma tələb edir.
Code Injection təsnifatı mobil tərtibat kontekstində üç əsas hücum növünü əhatə edir. Hər növ tətbiqin müxtəlif komponentlərindən istifadə edir və xüsusi qoruma üsulları tələb edir.
SQL Injection (SQLi) — yerli və ya uzaq verilənlər bazası sorğularının parametrləri vasitəsilə zərərli SQL kodunun daxil edilməsidir. Mobil tətbiqlərdə zəiflik cihazda SQLite ilə təhlükəsiz olmayan iş zamanı və ya REST API-ə HTTP sorğularının sətir birləşdirilməsi ilə qurulması zamanı yaranır.
Tipik hücum vektoru — dəyəri birbaşa SQL sorğusuna əlavə olunan axtarış və ya filtrləmə sahəsidir. Tərtibatçı parametrləşdirilmiş sorğular əvəzinə xam birləşdirmədən istifadə edərsə, hücum edən şəxs 1' OR '1'='1 kimi sətir ötürə bilər. OWASP Mobile Top 10 (2024) məlumatlarına görə, SQL Injection təhlükəsiz olmayan məlumat saxlama kateqoriyasında mobil tətbiqlərdə ikinci ən çox rast gəlinən kritik zəiflik olaraq qalır.
SQLi-dən qorunma üç səviyyəyə əsaslanır: parametrləşdirilmiş sorğulardan istifadə (Java-da PreparedStatement, Android-də bindArgs ilə rawQuery), müştəri və server tərəfində giriş məlumatlarının valide edilməsi və verilənlər bazasının minimal icazələri.
Mobil tətbiqlərdə XSS hücumları WebView komponentinə — HTML məzmunu göstərən daxili brauzerə yönəldilir. Tətbiq WebView-ə xarici mənbələrdən məlumatları sanitizasiya olmadan yükləyərsə, hücum edən şəxs tətbiq kontekstində icra olunacaq JavaScript kodu daxil edə bilər.
XSS-in iki alt növü fərqləndirilir: Stored XSS — zərərli skript serverdə saxlanılır və səhifə hər açıldıqda icra olunur; Reflected XSS — kod URL və ya POST parametrləri vasitəsilə ötürülür və bir dəfə icra olunur. Mobil tətbiqlərdə digər istifadəçilərə WebView-də göstərilən şərhlər, rəylər və ya istifadəçi məzmunu vasitəsilə Stored XSS xüsusilə təhlükəlidir.
Qoruma tələb olunmadıqda WebView-də JavaScript-in söndürülməsini, Content Security Policy (CSP) istifadəsini və Android üçün Jsoup və ya iOS üçün SwiftSoup kimi kitabxanalar vasitəsilə HTML məzmununun sanitizasiyasını əhatə edir.
Command Injection — Runtime.exec(), ProcessBuilder və ya NSTask vasitəsilə qorunmayan çağırışlar yolu ilə cihazda sistem əmrlərinin icrasıdır. Mobil tətbiqlərdə hücum tətbiq istifadəçi məlumatlarını shell əmrlərinə və ya Intent-lərə ötürdükdə mümkündür.
Ən həssas yerlər fayl konvertasiyası, media ilə iş (ffmpeg, ImageMagick) və xarici kitabxanaların quraşdırılması funksiyalarıdır. Hücum edən şəxs cihazda ixtiyari kodu icra edəcək boru və ya yönləndirmə simvolu olan əmr ötürə bilər. Android sandbox vasitəsilə shell girişini qismən məhdudlaşdırır, lakin root girişi və ya PrivEsc istismarı olan tətbiqlər kompromatasiya edilə bilər.
Tövsiyə olunan qoruma — istifadəçi məlumatlarının emalı üçün Runtime.exec()-dən tam imtina, təhlükəsiz API-li kitabxanaların istifadəsi və xarici proseslərin ciddi izolyasiyası.
Code Injection mexanizmi Android və iOS platformalarında memarlıq fərqlərinə görə fərqlənir. Android-də inyeksiyalar çox vaxt Intent — tətbiq komponentləri arasında ötürülən sistem mesajı ilə əlaqəlidir. Hücum edən şəxs SQL kodu və ya shell əmrləri olan extra məlumatları olan zərərli Intent göndərə bilər.
iOS-da hücumlar daha çox Interprocess Communication (XPC), Universal Links və URL Scheme emalı mexanizmi vasitəsilə baş verir. Xarici mənbələrdən məlumatları yoxlamadan qəbul edən tətbiq inyeksiyalara qarşı həssas olur. Apple Security Research (2025) məlumatlarına görə, iOS tətbiqlərindəki zəifliklərin təxminən 12%-i giriş məlumatlarının kifayət qədər sanitizasiya edilməməsi ilə bağlıdır.
Hər iki platforma üçün ümumi vektor — yerli yaddaş (SQLite, Realm, UserDefaults) vasitəsilə hücumdur. Zərərli tətbiq ümumi qovluğa məlumat yaza bilərsə, hədəf tətbiq tərəfindən oxunarkən icra olunacaq kod daxil edə bilər.
Tipik hücum prosesi üç mərhələdən ibarətdir: kəşfiyyat — tətbiqin giriş nöqtələrinin (formal, deep link-lər, fayllar) təhlili, inyeksiya — tapılan giriş nöqtəsi vasitəsilə zərərli yükün ötürülməsi və istismar — məlumatlara və ya funksionallığa giriş əldə etməklə inyeksiyanın icrası. Bu dövrü başa düşmək tərtibatçıya hər mərhələdə qoruma layihələndirməyə kömək edir.
Android üçün Kotlin və iOS üçün Swift-də Code Injection-in konkret nümunələrini nəzərdən keçirək. Hər nümunə zəif nümunəni və onun təhlükəsiz alternativini göstərir.
Birinci nümunə — sorğu sətrinin istifadəçi girişi ilə birbaşa birləşdirilməsidir. userInput = "1' OR '1'='1" dəyərində sorğu bir əvəzinə cədvəlin bütün sətirlərini qaytaracaq.
// ZƏİF: sətirlərin birləşdirilməsi
fun getUserById(userInput: String): List<User> {
val db = openOrCreateDatabase()
val query = "SELECT * FROM users WHERE id = " + userInput
return db.rawQuery(query, null)
}
// TƏHLÜKƏSİZ: parametrləşdirilmiş sorğu
fun getUserByIdSafe(userInput: String): List<User> {
val db = openOrCreateDatabase()
val query = "SELECT * FROM users WHERE id = ?"
return db.rawQuery(query, arrayOf(userInput))
}
İkinci nümunə WKWebView-də istifadəçi HTML məzmununun səhv və düzgün yüklənməsini göstərir. SwiftSoup istifadəsi göstərilmədən əvvəl zərərli skriptləri silməyə imkan verir.
// ZƏİF: birbaşa HTML yükləmə
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)
// TƏHLÜKƏSİZ: SwiftSoup ilə sanitizasiya
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
userComment,
Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)
Üçüncü nümunə — Runtime.exec()-in istifadəçi arqumentləri ilə çağırılmasının təhlükəsi və sabit API-li kitabxana vasitəsilə təhlükəsiz alternativ.
// ZƏİF: istifadəçi girişi ilə shell əmri
fun convertVideo(inputPath: String) {
val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
Runtime.getRuntime().exec(cmd)
}
// TƏHLÜKƏSİZ: arqumentlərin izolyasiyası
fun convertVideoSafe(inputPath: String) {
val cmd = listOf(
"ffmpeg", "-i", inputPath,
"-vcodec", "libx264", "output.mp4"
)
ProcessBuilder(cmd).start()
}
Code Injection-dən qorunma kod, infrastruktur və tərtibat proseslərini əhatə edən sistematik yanaşma tələb edir. Heç bir tək metod tam təhlükəsizliyi təmin etmir — təcrübələrin kombinasiyası zəruridir.
Birinci səviyyə — qarşısının alınması: bütün giriş məlumatlarının ciddi valide edilməsi. Tətbiqin istifadəçidən, digər tətbiqdən və ya şəbəkədən aldığı hər bir sahə növünə, uzunluğuna və formatına görə yoxlanılmalıdır. OWASP ESAPI kimi kitabxanalar ümumi ssenarilər üçün hazır validatorlar təqdim edir.
İkinci səviyyə — sanitizasiya və ekranlaşdırma: məlumatların SQL sorğularında, HTML şablonlarında və ya shell əmrlərində istifadə edilməzdən əvvəl çevrilməsi. Parametrləşdirilmiş sorğular SQL Injection-u tamamilə aradan qaldırır, HTML ekranlaşdırması isə XSS-in qarşısını alır. Android-də SQLite ilə iş üçün bind-parametrləri avtomatik tətbiq edən Room ORM-dən istifadə edin.
Üçüncü səviyyə — icazələrin minimallaşdırılması: tətbiq minimal zəruri hüquqlarla işləməlidir. Verilənlər bazası, fayl sistemi və proseslərarası kommunikasiya üçün ən az imtiyaz prinsipindən istifadə edin. iOS bu prinsipi tətbiq sandbox-u vasitəsilə, Android isə icazə modeli və proses izolyasiyası vasitəsilə həyata keçirir.
Dördüncü səviyyə — monitorinq və reaksiya: şübhəli əməliyyatların qeydiyyatı, anomaliyaların aşkarlanması və təkrarlanan hücumlarda avtomatik bloklama. Firebase App Check kimi alətlər kompromatasiya edilmiş müştərilərdən saxta sorğuları aşkarlamağa kömək edir. RASP (Runtime Application Self-Protection) inteqrasiyası inyeksiyaları icra zamanı bloklamağa imkan verir.
Google Project Zero (2025) araşdırmasına görə, bu dörd səviyyənin kombinasiyası Code Injection vasitəsilə uğurlu hücum riskini 94% azaldır. Tərtibatçılara qoruma mexanizmlərini zəiflik aşkar edildikdən sonra deyil, memarlığın layihələndirilməsi mərhələsində tətbiq etmək tövsiyə olunur.
Tez-tez verilən suallar
Code Injection — hücum edən şəxsin tətbiqə məlumat deyil, kod ötürməsidir. Məsələn, istifadəçi adı əvəzinə tətbiqin öz verilənlər bazasında icra etdiyi SQL sorğusu göndərir, başqalarının qeydlərinə giriş əldə edir.
SQL Injection SQL sorğuları vasitəsilə verilənlər bazasına hücum edir, qeydləri oxumağa və dəyişdirməyə imkan verir. XSS istifadəçinin brauzerində icra üçün WebView-ə JavaScript kodu daxil edir. Fərqli məqsədlər, lakin ümumi mexanizm — giriş məlumatlarının kifayət qədər valide edilməməsi.
SQLite üçün Room parametrləşdirilmiş sorğularla istifadə edin, WebView-də JavaScript-i söndürün, kod gizlətmək üçün ProGuard/R8 tətbiq edin və istifadəçi məlumatlarını heç vaxt Runtime.exec()-ə ötürməyin. Təhlükəsizlik yamaları ilə asılılıqları mütəmadi yeniləyin.
Bəli, iOS tətbiqləri Core Data (xam sorğular) vasitəsilə SQL Injection, WKWebView vasitəsilə XSS və Process vasitəsilə Command Injection üçün həssasdır. iOS sandbox hücumun miqyasını məhdudlaşdırır, lakin tam qarşısını almır. İstifadədən əvvəl həmişə məlumatları sanitizasiya edin.
Mənbə kodunun skan edilməsi üçün SAST (Static Analysis) — SonarQube, MobSF və ya QARK kimi alətlərdən istifadə edin. Əlavə olaraq işləyən tətbiqi test etmək üçün DAST skanerləri tətbiq edin: bütün giriş sahələrinə xüsusi formalaşdırılmış sətirlər daxil edin (', OR 1=1, <script>).
Nəticə
Açar təslim mobil tətbiq hazırlayacağıq
IT Sectr 2017-ci ildən startaplar və bizneslər üçün iOS və Android tətbiqləri yaradır. Sizə məsləhət verəcəyik və ən yaxşı həlli təklif edəcəyik.
Həm də oxuyun