Mobil ilovalarda kirish ma'lumotlarini tekshirish — asoslar, tekshirish usullari va amalga oshirish

Kirish ma'lumotlarini tekshirish nima?

Kirish ma'lumotlarini tekshirish — foydalanuvchidan, tashqi xizmatdan yoki boshqa komponentdan ilovaga kelayotgan ma'lumotlarning kutilgan mezonlarga mosligini tekshirish. Bu mezonlarga ma'lumot turi (satr, son, sana), format (email, URL, telefon), qiymat diapazoni (yosh 18 dan 120 gacha), uzunlik (parol 8 dan 128 belgigacha) va ruxsat etilgan belgilar (faqat lotin harflari, raqamlar, defis) kiradi. Validatsiyasiz ilova bajarish xatolariga, ma'lumotlarning buzilishiga yoki xavfsizlik zaifliklariga olib kelishi mumkin bo'lgan ma'lumotlarni qayta ishlashi mumkin.

Nega validatsiya xavfsizlikning kritik elementi hisoblanadi?

Kirish ma'lumotlari validatsiyasining yo'qligi SQL Injection, XSS, Command Injection, Path Traversal va Buffer Overflow kabi zaifliklarning asosiy sababidir. MITRE CWE (2025) ma'lumotlariga ko'ra, CWE-20 (Improper Input Validation) eng xavfli dasturiy xatolar reytingida ikkinchi o'rinni egallaydi. Validatsiya Defense in Depth xavfsizlik modelida birinchi himoya chizig'idir: u noto'g'ri ma'lumotlarni tizimning boshqa komponentlariga yetib bormasdan kesib tashlaydi.

Validatsiya vs Sanitizatsiya

Validatsiya mezonlarga mos kelmaydigan ma'lumotlarni rad etadi. Sanitizatsiya (tozalash) xavfli qismlarni olib tashlash yoki kodlash orqali ma'lumotlarni o'zgartiradi. Masalan, HTML-mazmun kiritilganda validatsiya matn uzunligini tekshirishi mumkin, sanitizatsiya esa HTML Purifier yoki DOMPurify kutubxonasi orqali script-teglarini olib tashlashi mumkin. Sanitizatsiya validatsiyani almashtirmaydi: ular juft bo'lib ishlaydi. Validatsiya "ruxsat berilgan/taqiqlangan" siyosati, sanitizatsiya esa "ishlatishdan oldin tozalangan".

Kirish ma'lumotlari validatsiyasining turlari

Validatsiya tekshirish chuqurligiga qarab tasniflanadi. Format validatsiyasi eng sodda va eng tezdir, biznes validatsiyasi esa eng murakkab va kontekstga bog'liqdir. Har uchala daraja ketma-ket qo'llanilishi kerak: avval format, keyin semantika, so'ngra biznes-mantiq. Istalgan darajani o'tkazib yuborish tizimning noto'g'ri ishlashiga yoki zaiflikka olib kelishi mumkin.

Format validatsiyasi

Ma'lumot turi, o'lchami, formati va ruxsat etilgan belgilarni tekshirish. Muntazam ifodalar, tillarning ichki turlari va validatsiya kutubxonalari orqali amalga oshiriladi. Misollar: UUID ni tekshirish (8-4-4-4-12 o'n oltilik raqam formati), telefon raqamini tekshirish (faqat raqamlar, boshida +, 7 dan 15 belgigacha), butun sonni tekshirish (Integer.MIN_VALUE — Integer.MAX_VALUE diapazonidagi qiymat). Format validatsiyasi istalgan kiritish maydoni uchun minimal zarur darajadir.

Semantik validatsiya

Ma'lumotlarning predmet sohasi kontekstida mantiqiy to'g'riligini tekshirish. Masalan: boshlanish sanasi tugash sanasidan kech emas, yosh tizim uchun oqilona chegaralarda, koordinatalar xizmat hududida. Semantik validatsiya biznes kontekstini tushunishni talab qiladi va faqat format asosida bajarilmaydi. Misol: "chiptalar soni" maydoni format tekshiruvidan o'tishi mumkin (butun son, > 0), lekin semantik jihatdan bo'sh o'rinlar sonidan oshmasligi kerak.

Biznes validatsiya

Eng murakkab daraja — ma'lumotlarning ilovaning biznes qoidalariga mosligini tekshirish. Misollar: foydalanuvchi yagona administratorni o'chira olmaydi, buyurtma summasi kredit limitidan oshmaydi, mahsulot faqat mavjud bo'lsa buyurtma qilinishi mumkin. Biznes validatsiya ko'pincha ma'lumotlar bazasi so'rovlarini yoki tashqi xizmatlarni talab qiladi va format hamda semantik tekshiruvlardan keyin bajariladi. Biznes validatsiya xatolari foydalanuvchilar noroziligining eng keng tarqalgan sababidir.

Mijoz va server validatsiyasi

Mijoz tomonidagi validatsiya (brauzerda yoki mobil ilovada) foydalanuvchi qulayligi uchun kerak: ma'lumotlarni serverga yubormasdan zudlik bilan fikr bildirish. Biroq server validatsiyasi yagona ishonchli usuldir, chunki mijoz kodini har doim chetlab o'tish mumkin. So'rovlarni dasturchi vositalari, Postman yoki proksi (Burp Suite) orqali yuboring — mijoz validatsiyasi mavjud bo'lishdan to'xtaydi. PortSwigger Research (2025) ma'lumotlariga ko'ra, sinovdan o'tgan veb-ilovalarning 90% dan ortig'i kamida bitta maydon uchun faqat mijoz validatsiyasiga tayanadi.

Qoida: mijoz — UX uchun, server — xavfsizlik uchun

Mijoz validatsiyasi yuborish tugmasini o'chirishi, xatolarni belgilashi, maslahatlarni ko'rsatishi mumkin. Server validatsiyasi har bir parametrning majburiy tekshiruvidir, hatto mijoz uni allaqachon tekshirgan bo'lsa ham. Ikkala darajada validatsiyani takrorlash standart amaliyotdir. Server ma'lumotlarni mijoz mavjud bo'lmagandek tekshirishi kerak. Bu o'zgartirilgan so'rovlar, avtomatlashtirilgan hujumlar va zararli mijozlardan himoyalanishni kafolatlaydi.

Mijoz validatsiyasini amalga oshirish

Vebda — HTML5 atributlari (required, pattern, min/max, type="email") va JavaScript. Mobil ilovalarda — matn maydonlarining native validatsiyalari (Android-da InputFilter, iOS-da textField(:shouldChangeCharactersIn:)). React uchun React Hook Form va Formik, Vue uchun Vuelidate, Angular Reactive Forms — mijoz validatsiyasi uchun mashhur kutubxonalar. Ularning barchasi maxsus qoidalar va asinxron validatsiyani (serverda login yagonaligini tekshirish) qo'llab-quvvatlaydi.

// Express va Joi bilan server validatsiyasi namunasi
const Joi = require('joi');

const userSchema = Joi.object({
    email: Joi.string()
        .email()
        .required()
        .max(255),
    age: Joi.number()
        .integer()
        .min(18)
        .max(120)
        .required(),
    password: Joi.string()
        .pattern(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,128}$/)
        .required()
});

app.post('/api/users', async (req, res) => {
    const { error, value } = userSchema.validate(req.body);
    if (error) {
        return res.status(400).json({
            error: error.details[0].message
        });
    }
    // value — allaqachon tekshirilgan va xavfsiz ma'lumotlar
    const user = await User.create(value);
    res.status(201).json(user);
});

Mobil ilovalarda validatsiya

Mobil ilovalar ma'lumot validatsiyasiga alohida talablar qo'yadi. Ekran kichikroq — xatolar ixcham bo'lishi kerak, klaviatura kontekstli (raqamlarni kiritish uchun raqamli), tekshiruv esa UI-ni bloklamaslik uchun asinxron bo'lishi kerak. Native platformalar odatda ishlatilishi kerak bo'lgan ichki validatsiya mexanizmlarini taqdim etadi. Android uchun Material Design Guidelines va iOS uchun Human Interface Guidelines validatsiya xatolarini ko'rsatish bo'yicha batafsil tavsiyalarni o'z ichiga oladi.

Android-da validatsiya (Jetpack Compose)

Jetpack Compose state-boshqaruv orqali validatsiyaga deklarativ yondashuvni taklif qiladi. Har bir kiritish maydoni holatga (MutableState) bog'langan, xato esa joriy qiymat asosida hisoblanadi. Compose Validator kutubxonasi qoidalarni yaratishni soddalashtiradi: required, email, min/max length, pattern. Validatsiya matn o'zgarganda (onValueChange) yoki formani yuborishga urinishda ishga tushadi. Xatoni faqat birinchi yuborishdan keyin yoki foydalanuvchi kiritishni tugatgandan so'ng (debounce 300-500ms) ko'rsatish tavsiya etiladi.

iOS-da validatsiya (SwiftUI)

SwiftUI formaning ichki validatsiya mexanizmiga ega emas, lekin uni Combine va property wrappers orqali oson amalga oshirish imkonini beradi. Maydon qiymati uchun @State, xato uchun esa hisoblanadigan xususiyatdan foydalaning. ValidatedPropertyKit freymvorki tayyor dekoratorlarni taqdim etadi: @Validated().email(), @Validated().range(18...120). iOS tavsiyasi — kiritish darajasida xatolar sonini kamaytirish uchun klaviatura turlaridan (UIKeyboardType.emailAddress, .numberPad) va auto-capitalization-dan foydalaning.

Flutter-da validatsiya

Flutter validator-kolbek orqali ichki validatsiyaga ega Form va TextFormField sinflarini taqdim etadi. Har bir maydon xatoni satr sifatida yoki ma'lumotlar to'g'ri bo'lsa null qaytaradi. FormState.validate() formaning barcha maydonlarini tekshirishni ishga tushiradi. Murakkab holatlar uchun reactive_forms paketi: maxsus validatorlar, asinxron tekshiruv, dinamik qoidalar. Flutter Web va mobil versiyalar bir xil API dan foydalanadi, bu esa xizmat ko'rsatishni soddalashtiradi.

// Flutter-da forma validatsiyasi namunasi
Form(
    key: _formKey,
    child: Column(
        children: [
            TextFormField(
                decoration: InputDecoration(labelText: 'Email'),
                validator: (value) {
                    if (value == null || value.isEmpty) {
                        return 'Email is required';
                    }
                    if (!RegExp(r'^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$')
                            .hasMatch(value)) {
                        return 'Enter a valid email';
                    }
                    return null;
                },
            ),
            ElevatedButton(
                onPressed: () {
                    if (_formKey.currentState!.validate()) {
                        // Process valid data
                    }
                },
                child: Text('Submit'),
            ),
        ],
    ),
)

Validatsiya texnikalari va vositalari

Zamonaviy freymvorklar ehtiyojlarning 80% ini qoplaydigan ichki validatorlarni taqdim etadi. Qolgan 20% maxsus qoidalar, muntazam ifodalar yoki mavjudlarning kompozitsiyasini talab qiladi. Asosiy tamoyil — validatsiya deklarativ bo'lishi kerak, shunda uni oson o'qish, test qilish va qo'llab-quvvatlash mumkin. Kontrollerlar va ekranlar bo'ylab yoyilgan validatsiya mantig'idan qoching — uni alohida sinflarga yoki sxemalarga chiqaring.

White-list vs Black-list yondashuvlari

White-list (oq ro'yxat) — qaysi ma'lumotlarga ruxsat berilganini aniqlaysiz, qolgan hammasi rad etiladi. Black-list — qaysi ma'lumotlar taqiqlanganini aniqlaysiz, qolgan hammasi o'tkaziladi. White-list har doim ishonchliroq: qaysi ma'lumotlar o'tishini aniq bilasiz. Black-list barcha mumkin bo'lgan hujumlarni oldindan ko'rishni talab qiladi, bu esa imkonsizdir. Misol: yoshni tekshirishda white-list (faqat 18 dan 120 gacha raqamlar) ishlating, black-list emas ("0", "-1", "999999" ni taqiqlash).

Muntazam ifodalar — kuch va xavf

Muntazam ifodalar format validatsiyasi uchun samarali vositadir, lekin ular ReDoS-hujumlarining (Regular Expression Denial of Service) manbai bo'lishi mumkin. Ba'zi naqshlar (masalan, (a+)+b) uzun satrlarda katastrofik backtrackingga olib keladi va server protsessorini to'liq yuklaydi. Sinalgan regex-kutubxonalardan foydalaning va muntazam ifodani qo'llashdan oldin satr uzunligini cheklang. Murakkab holatlar uchun (email, URL) o'z muntazam ifodalaringizni yozish o'rniga tillarning ichki parserlaridan foydalaning.

Validatsiyada odatiy xatolar

Hatto tajribali dasturchilar ham validatsiyani amalga oshirishda xato qiladilar. Eng keng tarqalganlari: faqat mijoz tomonidagi validatsiya, haddan tashqari qattiq qoidalar (parol "Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters"), axborot bermaydigan xato xabarlari ("Error: invalid input") va chegaraviy holatlarni (boshida/oxirida bo'sh joylar, Unicode belgilar, bo'sh satrlar) e'tiborsiz qoldirish. Bu xatolarning har biri UX ni yomonlashtiradi va formalarning konversiyasini pasaytirishi mumkin.

• Faqat mijoz validatsiyasi — eng xavfli xato: istalgan so'rov Postman yoki cURL orqali soxtalashtirilishi mumkin
• Haddan tashqari qattiq qoidalar — foydalanuvchilarni uzoqlashtiradi: OWASP ro'yxatdan o'tishda minimal talablarni tavsiya qiladi
• Unicode-ni e'tiborsiz qoldirish — satr uzunligini belgilar emas, baytlarda tekshirish o'zbekcha, xitoycha, emoji belgilarini buzadi
• Axborot bermaydigan xatolar — "Invalid format" o'rniga "Email must contain @ symbol after local part"
• Bo'sh maydonni tekshirish — if (value) bo'sh satrni noldan, false dan yoki "0" dan ajratmaydi

Eng yaxshi amaliyot — unit-testlar bilan qoplangan markazlashtirilgan validatsiya tizimi. Har bir qoida alohida tekshirilishi kerak: chegaraviy qiymatlar, to'g'ri ma'lumotlar, odatiy hujumlar (SQLi-urinishlar, XSS-payloads, juda uzun satrlar). Validatsiya bo'yicha regressiya testlari refaktoring paytida qoidalarning tasodifan zaiflashishining oldini oladi. Tasodifiy ma'lumotlarni yaratish va validatsiyaning istisno bilan ishlamay qolmasligini tekshirish uchun property-based testing (QuickCheck, fast-check) dan foydalaning.