SQL Injection mobil inkişafda: bu nədir, hücum metodları və qorunma

SQL Injection nədir?

SQL Injection — tətbiq istifadəçi məlumatları ilə sətirlərin birləşdirilməsi (konkatenasiya) yolu ilə SQL sorğusu yaratdıqda yaranan zəiflikdir. Təcavüzkar sorğu parametrinə xüsusi qurulmuş sətir ötürür ki, bu da SQL əmrinin strukturunu dəyişdirir. Daxil edilən sətir məlumat olmaq əvəzinə SQL kodunun bir hissəsinə çevrilir və bu, hücumçuya verilənlər bazasına ixtiyari sorğular yerinə yetirməyə imkan verir. Verizon Data Breach Report (2025) məlumatlarına görə, SQL Injection tədqiq edilmiş bütün məlumat sızmalarının 8%-də mövcuddur.

SQL Injection niyə hələ də aktualdır?

Zəifliyin tanınmasına baxmayaraq (ilk qeydlər — 1990-cı illərin sonu), SQL Injection müasir tətbiqlərdə rast gəlinir. Səbəb — insan faktoru: tərtibatçılar koddakı sətir konkatenasiyasına yol verir, legacy-kod refaktorinq edilmir, ORM-freymvorklar səhv istifadə olunur (məsələn, dəyərlərin sətirlər vasitəsilə əvəz edildiyi raw-sorğular). Veracode (2026) məlumatlarına görə, skan edilmiş bütün tətbiqlərin təxminən 14%-i ən azı bir SQLi zəifliyi ehtiva edir.

Təcavüzkar nə edə bilər?

Uğurlu SQL Injection təcavüzkara geniş imkanlar verir: parol heşləri və istifadəçilərin şəxsi məlumatları daxil olmaqla verilənlər bazasının istənilən cədvəllərini oxumaq; qeydləri dəyişdirmək və silmək; inzibati əməliyyatlar yerinə yetirmək (DROP TABLE, TRUNCATE); bəzi konfiqurasiyalarda — xp_cmdshell (MSSQL) və ya INTO OUTFILE (MySQL) vasitəsilə uzaqdan əmr yerinə yetirmək. Nəticələr — istifadəçi məlumatlarının sızmasından sistem üzərində nəzarətin tam itirilməsinə qədər.

SQL inyeksiyalarının növləri

SQL inyeksiyaları verilənlər bazasından məlumatların çıxarılması üsuluna görə təsnif edilir. Metodun seçimi tətbiqin sorğu nəticələrini və səhv mesajlarını necə emal etməsindən asılıdır. OWASP təsnifatı üç əsas növü ayırır: In-band (məlumatlar eyni kanal vasitəsilə çıxarılır), Inferential/Blind (məntiqi nəticələr) və Out-of-band (məlumatlar başqa kanal vasitəsilə ötürülür).

In-band SQL Injection (klassik)

Ən çox yayılmış növ. Təcavüzkar sorğu parametrinə SQL kodu daxil edir və daxil etmənin nəticəsi birbaşa server cavabında görünür. İki alt növ: Error-based (BD səhv mesajları vasitəsilə) və UNION-based (UNION SELECT operatoru vasitəsilə). Error-based səhv mesajlarından məlumat istifadə edir, məsələn, cədvəlin adını və ya sorğunun strukturunu aşkar edə bilən MySQL sintaksis xətası. UNION-based qanuni sorğunun nəticələrini verilənlər bazasının digər cədvəllərindən olan məlumatlarla birləşdirməyə imkan verir.

Blind SQL Injection (kor)

Tətbiq sorğunun nəticələrini və ya səhv mesajlarını göstərmədikdə istifadə olunur. Təcavüzkar məntiqi şərtlərlə sorğular göndərərək və server cavabındakı fərqi təhlil edərək (məsələn, cavab müddəti və ya səhifənin məzmunu) „bəli/xeyr” tipli suallar verir. Time-based Blind SQLi şərtləri təsdiqləmək üçün gecikmə funksiyasından (SLEEP, WAITFOR DELAY) istifadə edir — əgər səhifə daha uzun yüklənirsə, şərt doğrudur. Bu metod çox yavaşdır — bir qeydin çıxarılması saatlarla çəkə bilər.

# Blind SQL Injection nümunəsi (time-based)
# Əgər SQLi həssasdırsa, SLEEP(2) şərt yerinə yetirildikdə icra olunur
import requests
import time

payload = "' OR IF(SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a',SLEEP(2),0) -- "
url = "http://example.com/user?id=1" + payload

start = time.time()
response = requests.get(url)
elapsed = time.time() - start

# Əgər cavab >2 saniyədən sonra gəlibsə — şifrənin ilk hərfi 'a'dır
print(f"Time: {elapsed:.2f}s - First letter is 'a'" if elapsed > 2 else "First letter is not 'a'")

Out-of-band SQL Injection

Məlumatlar HTTP cavabı vasitəsilə deyil, alternativ kanallar vasitəsilə ötürülür: DNS sorğuları, xarici serverə HTTP müraciətləri, SMTP. Tətbiq sorğunun nəticələrini qaytarmadıqda və səhvləri göstərmədikdə istifadə olunur. MySQL DNS sorğusunu başlada bilən LOAD_FILE() funksiyasını, MSSQL isə məlumatları uzaq SMB serverinə göndərmək üçün xp_dirtree funksiyasını dəstəkləyir. Out-of-band SQL Injection effektivdir, lakin təcavüzkarın serverində əlavə qurğular və BD-nin müəyyən funksiyalarının mövcudluğunu tələb edir.

SQL inyeksiyası necə işləyir?

SQL Injection mexanizmi SQL-in sətir literalları üçün dırnaqlardan istifadə etməsinə əsaslanır. Əgər tətbiq istifadəçi girişini escapingsiz birbaşa SQL sorğusuna yerləşdirirsə, təcavüzkar sətri „bağlaya” və ixtiyari SQL kodu əlavə edə bilər. Məsələn, SELECT * FROM users WHERE name = '$input' sorğusunda ' OR '1'='1 yerləşdirilməsi sorğunu SELECT * FROM users WHERE name = '' OR '1'='1' çevirir və bu, bütün istifadəçiləri qaytarır.

Klassik nümunə: autentifikasiyanın yan keçilməsi

Giriş formasını nəzərdən keçirək: SELECT * FROM users WHERE username = '$user' AND password = '$pass'. Əgər təcavüzkar username sahəsinə admin' -- daxil edər, şifrəni boş qoyarsa, nəticədə sorğu SELECT * FROM users WHERE username = 'admin' -- ' AND password = '' olur. -- simvolları sorğunun qalan hissəsini şərhə çevirir və şifrə yoxlaması şərti söndürülür. Server admin istifadəçisinin qeydini qaytarır və təcavüzkar şifrəni bilmədən sistemə daxil olur.

# SQL Injection nümunəsi — autentifikasiyanın yan keçilməsi
# ZəIF KOD: birbaşa sətir konkatenasiyası
def login_vulnerable(username, password):
    query = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'"
    cursor.execute(query)
    return cursor.fetchone() is not None

# username = "admin' --" şifrə yoxlamasını ləğv edir
# TƏHLÜKƏSİZ VERSİYA: parametrləşdirilmiş sorğu
def login_secure(username, password):
    query = "SELECT * FROM users WHERE username = %s AND password = %s"
    cursor.execute(query, (username, password))
    return cursor.fetchone() is not None

UNION-based: başqa cədvəllərin oxunması

UNION SELECT operatoru iki SELECT sorğusunun nəticələrini birləşdirməyə imkan verir. Əgər təcavüzkar zəif parametr taparsa, başqa cədvəldən sorğu ilə UNION SELECT əlavə edir. Məsələn: ' UNION SELECT username, password FROM admins --. Uğur şərti — hər iki sorğuda sütunların sayı uyğun olmalıdır. Sütunların sayı ORDER BY vasitəsilə müəyyən edilir (' ORDER BY 1--, sonra 2, 3... xətaya qədər). Sütunların sayını bilən təcavüzkar eyni sayda sahə ilə UNION SELECT yerləşdirir.

Mobil tətbiqlərdə SQL Injection

Mobil tətbiqlər SQL Injection ilə həm server tərəfində (API), həm də müştəri tərəfində — yerli verilənlər bazalarında (SQLite, Realm) qarşılaşır. Mobil API-də server SQLi riski veb-tətbiqlərə bənzəsə də, yerli BD əlavə vektor yaradır. Əgər tətbiq məlumatları SQLite-də saxlayır və sətir konkatenasiyası ilə sorğular yerinə yetirirsə, API vasitəsilə yerli BD-yə daxil olan zərərli məlumatlar sonrakı emal zamanı SQLi-yə səbəb ola bilər.

Android/iOS-da SQLite-də SQL Injection

Cihazdakı yerli SQLite bazası da SQL Injection-a qarşı həssasdır, əgər tətbiq sorğuları sətir konkatenasiyası ilə formalaşdırırsa. Android-də Content Providers və iOS-da Core Data standart olaraq parametrləşdirmədən istifadə edir, lakin raw-sorğular tərtibatçının diqqətini tələb edir. SQLite nöqtəli vergül vasitəsilə çoxsaylı sorğuları dəstəkləmir, bu da təcavüzkarın imkanlarını məhdudlaşdırır, lakin WHERE şərtləri vasitəsilə məlumatların oxunmasından qorumur. Həmişə Android-də selectionArgs və iOS-da parametrlərlə NSPredicate istifadə edin.

Mobil tətbiqin API-si vasitəsilə SQL Injection

Mobil tətbiqin müraciət etdiyi API hər hansı veb-server kimi həssasdır. Mobil tərtibatçılar tez-tez SQLi-nin yalnız backend problemi olduğunu düşünür, lakin zəiflik müştəridən parametrləri qəbul edən API-endpoint səviyyəsində yaranır. Məsuliyyətin bölünməsi qorumur: əgər backend tərtibatçısı sorğunu parametrləşdirməyi unudubsa, istifadəçinin mobil tətbiqi hücum vektoruna çevrilir. Backend-dən ORM və ya prepared statements istifadəsini tələb edin.

// Android-də yerli SQLite-də SQL Injection nümunəsi
// ZəIF KOD: birbaşa konkatenasiya
fun getUserVulnerable(db: SQLiteDatabase, userId: String): Cursor {
    return db.rawQuery(
        "SELECT * FROM users WHERE id = $userId", null
    )
}

// TƏHLÜKƏSİZ VERSİYA: selectionArgs vasitəsilə parametrləşdirmə
fun getUserSecure(db: SQLiteDatabase, userId: String): Cursor {
    return db.rawQuery(
        "SELECT * FROM users WHERE id = ?",
        arrayOf(userId)
    )
}

SQL inyeksiyalarının qarşısının alınması metodları

SQL Injection-dan qorunma sadə prinsipə əsaslanır: SQL sorğularında istifadəçi girişinə heç vaxt etibar etməyin. Yeganə etibarlı metod — sorğuların parametrləşdirilməsi (prepared statements), burada SQL kodu və məlumatlar ayrıca ötürülür. Bütün digər metodlar — escaping, validasiya, WAF — əlavə qorunma qatlarıdır, lakin parametrləşdirməni əvəz etmir. OWASP (2025) məlumatlarına görə, parametrləşdirmə SQL Injection hücumlarının 100%-nin qarşısını alır.

Prepared Statements (parametrləşdirilmiş sorğular)

Prepared statements istifadə edərkən SQL sorğusu əvvəlcə məlumatlar olmadan BD serveri tərəfindən kompilə edilir, sonra parametr dəyərləri ayrıca ötürülür. Verilənlər bazası parametrləri icra olunan kod kimi deyil, məlumat kimi qəbul edir. Təcavüzkar ' OR '1'='1 ötürsə belə, BD bunu SQL kodu deyil, sətir dəyəri kimi interpretasiya edir. Prepared statements bütün müasir dillər və freymvorklar tərəfindən dəstəklənir: PHP-də PDO, Java-da PreparedStatement, Python-da cursor.execute.

ORM-freymvorklar və Query Builderlər

Müasir ORM-lər (Hibernate, Entity Framework, SQLAlchemy, Room) sorğuları yerinə yetirərkən avtomatik olaraq parametrləşdirmədən istifadə edir, əgər tərtibatçı raw-sorğulara keçməzsə. Lakin ORM tam qorumur: JPA-da @Query(value = "SELECT * FROM users WHERE name = :name", nativeQuery = true) kimi konstruksiyalar parametrlərin konkatenasiya deyil, adlandırılmış parametrlər vasitəsilə ötürülməsini tələb edir. Query Builderlər (Knex, jOOQ) də raw-metodlardan istifadə edilmədikdə sorğuları standart olaraq parametrləşdirir.

Sətirlərin escapinqi (əsas metod kimi tövsiyə edilmir)

Xüsusi simvolların escapinqi (mysql_real_escape_string) — SQL Injection-un bütün növlərindən qorumayan köhnəlmiş metoddur. Problem: escapinq kodlaşdırmadan asılıdır və çoxbaytlı kodlaşdırmalardan istifadə edərək yan keçilə bilər (məsələn, Asiya sistemlərində GBK). Escapinqi yalnız parametrləşdirmənin mümkün olmadığı legacy-kodda və həmişə daxil olan məlumatların növünün ciddi validasiyası ilə birlikdə istifadə edin.

BD üçün ən az imtiyaz prinsipi

Tətbiqin hesabı minimal zəruri hüquqlara malik olmalıdır: SELECT, INSERT, UPDATE, DELETE — yalnız tətbiq üçün həqiqətən lazım olan cədvəllər üzərində. Tətbiq hesabı üçün DROP, TRUNCATE, CREATE istifadəsini qadağan edin. Bu, uğurlu SQL Injection halında zərəri məhdudlaşdıracaq: təcavüzkar cədvəlləri silə və ya inzibati əməliyyatlar yerinə yetirə bilməyəcək.

SQL inyeksiyalarını aşkar etmək üçün alətlər

SQL Injection üçün müntəzəm test təhlükəsiz inkişaf pipeline-nın bir hissəsi olmalıdır. Statik analizin, dinamik skanermənin və əl ilə penetrasiya testinin kombinasiyası ən yaxşı nəticələri verir. Synopsys Cybersecurity Report (2025) məlumatlarına görə, avtomatik skanerlər SQLi zəifliklərinin 70%-ə qədərini tapır, lakin mürəkkəb Blind hücumları əl ilə test tələb edir.

• sqlmap — SQL Injection-un avtomatik aşkarlanması və istismarı üçün ən populyar alət
• OWASP ZAP — SQLi aktiv skaner modulları olan pulsuz DAST skaneri
• Burp Suite Scanner — SQL Injection-un avtomatik aşkarlanması ilə peşəkar alət
• SonarQube — SQLi nümunələri daxil olmaqla zəifliklər üçün statik kod analizi
• CodeQL — mənbə kodunda SQL inyeksiyalarını axtarmaq üçün semantik kod analizi

Mobil tətbiqlər üçün yerli SQLite analizi də vacibdir: bütün rawQuery çağırışlarını, ContentProvider sorğularını və rawQuery ilə Room sorğularını yoxlayın. Alətlər: Android Studio Lint (SQLite-də SQLi aşkarlayır), APK/IPA-nın avtomatik statik və dinamik analizi üçün MobSF (Mobile Security Framework). Həmçinin mobil tətbiq trafikinin proxy ələ keçirməsi ilə sqlmap vasitəsilə API-endpointləri test etmək tövsiyə olunur.