SQL Injection mobil ishlab chiqishda: bu nima, hujum usullari va himoya

SQL Injection nima?

SQL Injection — bu dastur foydalanuvchi ma'lumotlari bilan satrlarni birlashtirish (konkatenatsiya) orqali SQL so'rovini yaratganda yuzaga keladigan zaiflikdir. Tajovuzkor so'rov parametriga maxsus tuzilgan satrni yuboradi, bu SQL buyrug'ining tuzilishini o'zgartiradi. Kiritilgan satr ma'lumot bo'lish o'rniga SQL kodining bir qismiga aylanadi va bu tajovuzkorga ma'lumotlar bazasiga ixtiyoriy so'rovlarni bajarish imkonini beradi. Verizon Data Breach Report (2025) ma'lumotlariga ko'ra, SQL Injection tekshirilgan barcha ma'lumot sizib chiqishlarining 8 foizida mavjud.

Nega SQL Injection hali ham dolzarb?

Zaiflikning ma'lumligiga qaramay (birinchi eslatmalar — 1990-yillarning oxiri), SQL Injection zamonaviy ilovalarda uchraydi. Sabab — inson omili: dasturchilar koddagi satr konkatenatsiyasiga yo'l qo'yadi, legacy-kod refaktor qilinmaydi va ORM-freymvorklar noto'g'ri ishlatiladi (masalan, qiymatlarni satrlar orqali almashtirish bilan raw-so'rovlar). Veracode (2026) ma'lumotlariga ko'ra, skanerdan o'tkazilgan barcha ilovalarning taxminan 14 foizi kamida bitta SQLi zaifligini o'z ichiga oladi.

Tajovuzkor nima qilishi mumkin?

Muvaffaqiyatli SQL Injection tajovuzkorga keng imkoniyatlar beradi: parol xeshlari va foydalanuvchilarning shaxsiy ma'lumotlarini o'z ichiga olgan ma'lumotlar bazasining istalgan jadvallarini o'qish; yozuvlarni o'zgartirish va o'chirish; ma'muriy operatsiyalarni bajarish (DROP TABLE, TRUNCATE); ba'zi konfiguratsiyalarda — xp_cmdshell (MSSQL) yoki INTO OUTFILE (MySQL) orqali masofadan buyruq bajarish. Natijalar — foydalanuvchi ma'lumotlarining sizib chiqishidan tizim ustidan nazoratning to'liq yo'qolishigacha.

SQL inyeksiyalarining turlari

SQL inyeksiyalari ma'lumotlar bazasidan ma'lumotlarni chiqarish usuliga ko'ra tasniflanadi. Usulni tanlash dasturning so'rov natijalarini va xato xabarlarini qanday qayta ishlashiga bog'liq. OWASP tasnifi uchta asosiy turni ajratadi: In-band (ma'lumotlar bir xil kanal orqali chiqariladi), Inferential/Blind (mantiqiy xulosalar) va Out-of-band (ma'lumotlar boshqa kanal orqali uzatiladi).

In-band SQL Injection (klassik)

Eng keng tarqalgan tur. Tajovuzkor so'rov parametriga SQL kodini kiritadi va kiritish natijasi to'g'ridan-to'g'ri server javobida ko'rinadi. Ikki kichik tur: Error-based (ma'lumotlar bazasi xato xabarlari orqali) va UNION-based (UNION SELECT operatori orqali). Error-based xato xabarlaridan ma'lumotdan foydalanadi, masalan, jadval nomini yoki so'rov tuzilishini ochib berishi mumkin bo'lgan MySQL sintaksis xatosi. UNION-based qonuniy so'rov natijalarini ma'lumotlar bazasining boshqa jadvallaridagi ma'lumotlar bilan birlashtirish imkonini beradi.

Blind SQL Injection (ko'r)

Dastur so'rov natijalarini yoki xato xabarlarini ko'rsatmaganda qo'llaniladi. Tajovuzkor mantiqiy shartlar bilan so'rovlar yuborib va server javobidagi farqni tahlil qilib (masalan, javob vaqti yoki sahifa mazmuni) „ha/yo'q” tipidagi savollar beradi. Time-based Blind SQLi shartlarni tasdiqlash uchun kechikish funksiyasidan (SLEEP, WAITFOR DELAY) foydalanadi — agar sahifa uzoqroq yuklansa, shart to'g'ri. Bu usul juda sekin — bitta yozuvni chiqarish soatlab davom etishi mumkin.

# Blind SQL Injection namunasi (time-based)
# Agar SQLi zaif bo'lsa, SLEEP(2) shart bajarilganda ishlaydi
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

# Agar javob >2 soniyadan keyin kelgan bo'lsa — parolning birinchi harfi 'a'
print(f"Time: {elapsed:.2f}s - First letter is 'a'" if elapsed > 2 else "First letter is not 'a'")

Out-of-band SQL Injection

Ma'lumotlar HTTP javobi orqali emas, balki alternativ kanallar orqali uzatiladi: DNS so'rovlari, tashqi serverga HTTP murojaatlari, SMTP. Dastur so'rov natijalarini qaytarmaganda va xatolarni ko'rsatmaganida qo'llaniladi. MySQL DNS so'rovini boshlashi mumkin bo'lgan LOAD_FILE() funksiyasini, MSSQL esa ma'lumotlarni masofaviy SMB serveriga yuborish uchun xp_dirtree funksiyasini qo'llab-quvvatlaydi. Out-of-band SQL Injection samarali, ammo tajovuzkor serverida qo'shimcha sozlamalar va ma'lumotlar bazasining muayyan funksiyalari mavjudligini talab qiladi.

SQL inyeksiyasi qanday ishlaydi?

SQL Injection mexanizmi SQL satr literallari uchun qo'shtirnoqlardan foydalanishiga asoslanadi. Agar dastur foydalanuvchi kiritishini escapingsiz to'g'ridan-to'g'ri SQL so'roviga joylashtirsa, tajovuzkor satrni „yopib” va ixtiyoriy SQL kodini qo'shishi mumkin. Masalan, SELECT * FROM users WHERE name = '$input' so'rovida ' OR '1'='1 joylashtirish so'rovni SELECT * FROM users WHERE name = '' OR '1'='1' ga aylantiradi va bu barcha foydalanuvchilarni qaytaradi.

Klassik misol: autentifikatsiyani chetlab o'tish

Kirish formasini ko'rib chiqaylik: SELECT * FROM users WHERE username = '$user' AND password = '$pass'. Agar tajovuzkor username maydoniga admin' -- kiritsa va parolni bo'sh qoldirsa, natijadagi so'rov SELECT * FROM users WHERE username = 'admin' -- ' AND password = '' bo'ladi. -- belgilari so'rovning qolgan qismini sharhlaydi va parolni tekshirish sharti o'chiriladi. Server admin foydalanuvchisining yozuvini qaytaradi va tajovuzkor parolni bilmasdan tizimga kiradi.

# SQL Injection namunasi — autentifikatsiyani chetlab o'tish
# ZAIF KOD: to'g'ridan-to'g'ri satr konkatenatsiyasi
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' --" parol tekshiruvini bekor qiladi
# XAVFSIZ VERSIYA: parametrlangan so'rov
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: boshqa jadvallarni o'qish

UNION SELECT operatori ikkita SELECT so'rovining natijalarini birlashtirish imkonini beradi. Agar tajovuzkor zaif parametr topsa, boshqa jadvaldan so'rov bilan UNION SELECT qo'shadi. Masalan: ' UNION SELECT username, password FROM admins --. Muvaffaqiyat sharti — ikkala so'rovda ustunlar soni mos kelishi kerak. Ustunlar soni ORDER BY orqali aniqlanadi (' ORDER BY 1--, keyin 2, 3... xatogacha). Ustunlar sonini bilgan tajovuzkor bir xil sonli maydonlar bilan UNION SELECT joylashtiradi.

Mobil ilovalarda SQL Injection

Mobil ilovalar SQL Injection bilan ham server tomonida (API), ham mijoz tomonida — mahalliy ma'lumotlar bazalarida (SQLite, Realm) duch keladi. Mobil API-da server SQLi xavfi veb-ilovalarga o'xshash bo'lsa-da, mahalliy MB qo'shimcha vektor yaratadi. Agar ilova ma'lumotlarni SQLite-da saqlasa va satr konkatenatsiyasi bilan so'rovlar bajarsa, API orqali mahalliy MBga tushgan zararli ma'lumotlar keyingi qayta ishlash vaqtida SQLi sabab bo'lishi mumkin.

Android/iOS da SQLite da SQL Injection

Qurilmadagi mahalliy SQLite bazasi ham SQL Injectionga nisbatan zaif, agar ilova so'rovlarni satr konkatenatsiyasi bilan shakllantirsa. Android da Content Providers va iOS da Core Data standart ravishda parametrlashdan foydalanadi, ammo raw-so'rovlar dasturchining e'tiborini talab qiladi. SQLite nuqtali vergul orqali bir nechta so'rovlarni qo'llab-quvvatlamaydi, bu tajovuzkorning imkoniyatlarini cheklaydi, lekin WHERE shartlari orqali ma'lumotlarni o'qishdan himoya qilmaydi. Android da selectionArgs va iOS da parametrlar bilan NSPredicate dan foydalaning.

Mobil ilova API si orqali SQL Injection

Mobil ilova murojaat qiladigan API har qanday veb-server kabi zaifdir. Mobil dasturchilar ko'pincha SQLi faqat backend muammosi deb o'ylashadi, ammo zaiflik mijozdan parametrlarni qabul qiladigan API-endpoint darajasida yuzaga keladi. Mas'uliyatni taqsimlash himoya qilmaydi: agar backend dasturchisi so'rovni parametrlashni unutgan bo'lsa, foydalanuvchining mobil ilovasi hujum vektoriga aylanadi. Backenddan ORM yoki prepared statements foydalanishni talab qiling.

// Android da mahalliy SQLite da SQL Injection namunasi
// ZAIF KOD: to'g'ridan-to'g'ri konkatenatsiya
fun getUserVulnerable(db: SQLiteDatabase, userId: String): Cursor {
    return db.rawQuery(
        "SELECT * FROM users WHERE id = $userId", null
    )
}

// XAVFSIZ VERSIYA: selectionArgs orqali parametrlash
fun getUserSecure(db: SQLiteDatabase, userId: String): Cursor {
    return db.rawQuery(
        "SELECT * FROM users WHERE id = ?",
        arrayOf(userId)
    )
}

SQL inyeksiyalarining oldini olish usullari

SQL Injection dan himoya oddiy printsipga asoslanadi: SQL so'rovlarida foydalanuvchi kiritgan ma'lumotlarga hech qachon ishonmang. Yagona ishonchli usul — so'rovlarni parametrlash (prepared statements), bunda SQL kodi va ma'lumotlar alohida uzatiladi. Boshqa barcha usullar — escaping, validatsiya, WAF — qo'shimcha himoya qatlamlaridir, ammo parametrlashni almashtirmaydi. OWASP (2025) ma'lumotlariga ko'ra, parametrlash SQL Injection hujumlarining 100 foizining oldini oladi.

Prepared Statements (parametrlangan so'rovlar)

Prepared statements ishlatilganda, SQL so'rovi avval ma'lumotlarsiz MB serveri tomonidan kompilyatsiya qilinadi, keyin parametr qiymatlari alohida uzatiladi. Ma'lumotlar bazasi parametrlarni bajariladigan kod sifatida emas, balki ma'lumot sifatida qabul qiladi. Tajovuzkor ' OR '1'='1 yuborsa ham, MB buni SQL kodi emas, balki satr qiymati sifatida talqin qiladi. Prepared statements barcha zamonaviy tillar va freymvorklar tomonidan qo'llab-quvvatlanadi: PHP da PDO, Java da PreparedStatement, Python da cursor.execute.

ORM-freymvorklar va Query Builder lar

Zamonaviy ORM lar (Hibernate, Entity Framework, SQLAlchemy, Room) so'rovlarni bajarishda avtomatik ravishda parametrlashdan foydalanadi, agar dasturchi raw-so'rovlarga o'tmasa. Biroq ORM to'liq himoya qilmaydi: JPA da @Query(value = "SELECT * FROM users WHERE name = :name", nativeQuery = true) kabi konstruksiyalar parametrlarni konkatenatsiya emas, balki nomlangan parametrlar orqali uzatishni talab qiladi. Query Builder lar (Knex, jOOQ) ham raw-usullardan foydalanilmasa, so'rovlarni standart ravishda parametrlaydi.

Satrlarni escaping (asosiy usul sifatida tavsiya etilmaydi)

Maxsus belgilarni escaping (mysql_real_escape_string) — SQL Injection ning barcha turlaridan himoya qilmaydigan eskirgan usul. Muammo: escaping kodlashga bog'liq va ko'p baytli kodlashlar yordamida chetlab o'tilishi mumkin (masalan, Osiyo tizimlarida GBK). Escapingni faqat parametrlash mumkin bo'lmagan legacy-kodda va har doim kirish ma'lumotlari turini qat'iy validatsiyasi bilan birgalikda ishlating.

MB uchun eng kam imtiyoz printsipi

Ilovaning hisobi minimal zarur huquqlarga ega bo'lishi kerak: SELECT, INSERT, UPDATE, DELETE — faqat ilova uchun haqiqatan kerak bo'lgan jadvallarda. Ilova hisobi uchun DROP, TRUNCATE, CREATE dan foydalanishni taqiqlang. Bu muvaffaqiyatli SQL Injection holatida zararni cheklaydi: tajovuzkor jadvallarni o'chira olmaydi yoki ma'muriy operatsiyalarni bajara olmaydi.

SQL inyeksiyalarini aniqlash vositalari

SQL Injection uchun muntazam test xavfsiz rivojlanish pipeline ning bir qismi bo'lishi kerak. Statik tahlil, dinamik skanerlash va qo'lda penetratsion testning kombinatsiyasi eng yaxshi natijalarni beradi. Synopsys Cybersecurity Report (2025) ma'lumotlariga ko'ra, avtomatik skanerlar SQLi zaifliklarining 70 foizgacha topadi, ammo murakkab Blind hujumlari qo'lda test qilishni talab qiladi.

• sqlmap — SQL Injection ni avtomatik aniqlash va ekspluatatsiya qilish uchun eng mashhur vosita
• OWASP ZAP — SQLi faol skanerlash modullari bilan bepul DAST skaneri
• Burp Suite Scanner — SQL Injection ni avtomatik aniqlash bilan professional vosita
• SonarQube — SQLi na'munalarini o'z ichiga olgan zaifliklar uchun statik kod tahlili
• CodeQL — manba kodida SQL inyeksiyalarini qidirish uchun semantik kod tahlili

Mobil ilovalar uchun mahalliy SQLite tahlili ham muhim: barcha rawQuery chaqiruvlarini, ContentProvider so'rovlarini va rawQuery bilan Room so'rovlarini tekshiring. Vositalar: Android Studio Lint (SQLite da SQLi ni aniqlaydi), APK/IPA ni avtomatik statik va dinamik tahlil qilish uchun MobSF (Mobile Security Framework). Shuningdek, mobil ilova trafigini proksi orqali ushlash bilan sqlmap orqali API-endpointlarni test qilish tavsiya etiladi.