Xavfsizlik

Input validation — foydalanuvchi ma'lumotlarini to'g'ri tekshirish

02.06.2034
← Barcha maqolalar

Input validation deganda biz foydalanuvchidan kelgan har qanday ma'lumotni ishlatishdan oldin tekshirishni tushunamiz. Bu eng asosiy va eng ko'p e'tibordan chetda qoladigan himoya qatlami. Ko'pchilik dasturchi "men foydalanuvchini ishonaman" yoki "front-end'da tekshirdim, yetadi" deb o'ylaydi. Aslida har ikkalasi ham xato. Foydalanuvchini hech qachon ishonib bo'lmaydi va front-end'dagi tekshiruvni hujumchi bemalol chetlab o'tadi.

Whitelist vs Blacklist — qaysi biri to'g'ri?

Validation'da ikkita asosiy yondashuv mavjud: whitelist (ruxsat etilganlar ro'yxati) va blacklist (taqiqlanganlar ro'yxati). Blacklist'da siz "bu belgilar xavfli, ularni rad etaman" deb yozasiz. Lekin bu yondashuv juda zaif — chunki xavfli belgilarning hammasini bilib bo'lmaydi. Hujumchilar doim yangi usullar topadi. Whitelist'da esa siz "faqat shu belgilarga ruxsat beraman" deysiz. Bu yondashuv ancha xavfsiz. Misol uchun, telefon raqami uchun faqat raqamlar va "+" belgisiga ruxsat berasiz. Email uchun maxsus filter_var() funksiyasi ishlatasiz.

Server-side validation majburiy

JavaScript orqali front-end'da tekshirish foydali, lekin u faqat foydalanuvchi tajribasini yaxshilash uchun. Xavfsizlik nuqtai nazaridan u hech narsa bermaydi. Chunki hujumchi brauzerdagi JavaScript'ni o'chirib qo'yishi yoki to'g'ridan-to'g'ri HTTP so'rov yuborishi mumkin. Shuning uchun har bir validation server tomonida takrorlanishi shart. Bu qo'sh ish kabi ko'rinadi, lekin majburiy. Server-side validation'siz biror dastur xavfsiz bo'la olmaydi.

Ma'lumot turlariga qarab validation

Har bir ma'lumot turi o'z validation qoidalariga ega. Email uchun filter_var($email, FILTER_VALIDATE_EMAIL) ishlatiladi. URL uchun FILTER_VALIDATE_URL. Raqamlar uchun is_numeric() yoki ctype_digit(). Sana uchun DateTime klassi. Telefon raqami uchun regex orqali tekshirish — masalan O'zbekiston raqami uchun "^\+998[0-9]{9}$". Uzunlikni ham tekshirish kerak — juda uzun matn ham xavf bo'lishi mumkin (denial of service hujumi).

Fayl yuklash — alohida xavf

Foydalanuvchi yuklagan fayllar eng katta xavf manbalaridan biri. Faqat fayl kengaytmasiga ishonib bo'lmaydi — hujumchi .php fayliga .jpg nom berishi mumkin. Shuning uchun fayl turini mime type orqali tekshirish kerak. Bundan tashqari fayl o'lchamini cheklash, fayl nomini o'zgartirish (oddiy random string), faylni web root tashqarisida saqlash kerak. Va eng muhimi — yuklangan fayl PHP sifatida ishga tushmasligi uchun server konfiguratsiyasini to'g'rilash kerak.

Validation xato xabarlari

Validation muvaffaqiyatsiz bo'lganda foydalanuvchiga nima xato ekanini aniq aytish kerak. Lekin xato xabarlari ortiqcha texnik ma'lumot bermasligi shart. Masalan, "Email noto'g'ri formatda" yaxshi xabar. Lekin "SQLSTATE[23000]: Integrity constraint violation" yomon — bu hujumchi uchun ma'lumotlar bazasi tuzilishi haqida ma'lumot beradi.

Sayt.uz amaliyot

Sayt.uz platformasida har bir forma server tomonida tekshiriladi. Email, telefon, parol kuchliligi, fayl turi va o'lchami — barcha narsa whitelist yondashuvi bilan validate qilinadi. Foydalanuvchi tajribasi uchun front-end validation ham qo'shilgan, lekin u hech qachon yagona himoya bo'lmaydi. Saytingizni Sayt.uz hostingda joylashtirib, domen va SSL sertifikat orqali to'liq xavfsizlik ta'minlashingiz mumkin.

O'xshash maqolalar

🔐 Parol menejerlar — Bitwarden, 1Password, LastPass va KeePass tanlovi 🍯 Honeypot — formada yashirin maydon, botlarni ushlaydi va spamni to'xtatadi 📄 /.well-known/security.txt — xavfsizlik bo'yicha bog'lanish standart 📋 GDPR moslik — Yevropa ma'lumotlarini himoya qilish majburiyatlari
🌐 Til
🇺🇿 O'zbek 🇺🇿 Ўзбек 🇷🇺 Русский 🇬🇧 English