Veb Xavfsizligi Haqida Eng Ko'p Beriladigan 7 Muhim Savol

Kirish: Veb xavfsizligi nega har bir dasturchi uchun zarur?

Har bir dasturchi faoliyati davomida kamida bir marta g'alati xatoliklarga, tushunarsiz blokirofkalarga yoki xavfsizlik muammolariga duch keladi. Ko'pincha CORS xatosi tufayli API ishlamay qoladi, autentifikatsiya tizimini tanlashda ikkilanishlar paydo bo'ladi yoki foydalanuvchi ma'lumotlarini himoya qilishda qaysi usul to'g'ri ekanligi bahsli bo'lib qoladi. Veb xavfsizligi faqat yirik korporatsiyalar uchun emas, balki kichik Telegram botlar, shaxsiy bloglar va e-tijorat loyihalari uchun ham birdek dolzarbdir.

Ushbu maqolada dasturchilar va veb-ishlab chiquvchilar orasida veb xavfsizligi bo'yicha eng ko'p beriladigan 7 ta muhim savolga amaliy, tushunarli va tajribaga asoslangan javoblarni jamladik.

1. Nega CORS xatosi chiqadi va uni qanday to'g'ri to'g'rilash kerak?

CORS (Cross-Origin Resource Sharing) xatosi — yangi boshlovchi frontend va backend dasturchilarning eng birinchi 'bosh og'rig'i' hisoblanadi. Ko'pchilik buni server xatosi deb o'ylaydi, ammo aslida CORS — brauzer tomonidan foydalanuvchini himoya qilish uchun o'rnatilgan xavfsizlik mexanizmidir.

Brauzer sizning frontend ilovangiz (masalan, http://localhost:3000) mutlaqo boshqa manzildagi backend API'ga (masalan, http://api.pycoder.uz) so'rov yuborganida, xavfsizlik yuzasidan backend'dan ushbu manzilga ruxsat bor-yo'qligini tekshiradi. Agar backend kerakli Access-Control-Allow-Origin sarlavhasini qaytarmasa, brauzer javobni bloklaydi.

Noto'g'ri yechim: barcha so'rovlarga ko'r-ko'rona Access-Control-Allow-Origin: * berib yuborish. To'g'ri yechim esa backend sozlamalarida faqat ishonchli frontend domenlarini aniq ko'rsatishdir:

# Django loyihasida django-cors-headers sozlamasi
CORS_ALLOWED_ORIGINS = [
    'https://pycoder.uz',
    'https://admin.pycoder.uz',
]

2. JWT token yoki Session: Qaysi biri xavfsizroq va qachon ishlatiladi?

Bu savol autentifikatsiya tizimini qurishda eng ko'p uchraydigan bahslardan biridir. Har ikkala usulning o'z o'rni va xavfsizlik talablari mavjud:

• Session asosidagi autentifikatsiya: Ma'lumot server xotirasida yoki Redis kabi bazada saqlanadi, brauzerga faqat maxfiy session_id cookie orqali yuboriladi. Agar foydalanuvchi hisobini darhol to'xtatish (revoke qilish) kerak bo'lsa, bu juda oson kechadi. Monolit veb-saytlar va klassik Django ilovalari uchun eng xavfsiz va qulay tanlovdir.
• JWT (JSON Web Token): Server holatsiz (stateless) ishlaydi, ya'ni sessiyani bazada saqlamaydi. Tokenning o'zi shifrlanmagan, faqat raqamli imzolangan bo'ladi. Mobil ilovalar, mikroxizmatlar va SPA (React/Vue) uchun qulay. Ammo JWT'ning asosiy kamchiligi — uni muddatidan oldin bekor qilish qiyinligi.

Eng xavfsiz amaliyot: JWT tokenlarini brauzerning localStorage qismida emas, balki HttpOnly va Secure bayroqchalari o'rnatilgan kuki (cookie) ichida saqlash tavsiya etiladi. Bu token o'g'irlanishining oldini oladi.

3. XSS (Cross-Site Scripting) hujumi nima va undan qanday saqlanish mumkin?

XSS hujumi paytida tajovuzkor sayt sahifasiga begona JavaScript kodini joylab yuboradi. Agar sayt foydalanuvchi kiritgan ma'lumotlarni hech qanday filtrsiz to'g'ridan-to'g'ri ekranga chiqarsa, kiritilgan zararli skript boshqa foydalanuvchilar brauzerida ishga tushib, ularning kukilarini yoki tokenlarini o'g'irlashi mumkin.

Zamonaviy React yoki Vue kabi frameworklar o'zgaruvchilarni avtomatik tarzda ekranlashtiradi (escape qiladi), ya'ni <script> teglarini oddiy matn sifatida chiqaradi. Biroq quyidagi holatlardan qat'iyan qochish zarur:

• React ilovalarida dangerouslySetInnerHTML xususiyatidan tekshirilmagan matnlar uchun foydalanmaslik.
• Backend'da doimo kiruvchi ma'lumotlarni tozalash (HTML sanitization).
• Saytda Content Security Policy (CSP) sarlavhasini sozlash orqali tashqi zararli skriptlar yuklanishini taqiqlash.

4. CSRF hujumidan himoyalanish nega muhim?

CSRF (Cross-Site Request Forgery) — foydalanuvchi o'zi bilmagan holda, uning nomidan autentifikatsiya qilingan veb-saytga so'rov yuborish hujumidir. Masalan, siz bank saytida tizimga kirgansiz, so'ngra boshqa zararlangan saytga o'tsangiz, o'sha sayt yashirincha sizning nomingizdan bankka pul o'tkazish so'rovini yuborishi mumkin.

Zamonaviy yechimlar:

1. CSRF tokenlari: Django kabi tizimlar har bir forma uchun maxfiy csrf_token talab qiladi.
2. SameSite Cookie: Kukilarga SameSite=Lax yoki SameSite=Strict atributini berish orqali boshqa saytlardan yuboriladigan so'rovlarda kuki birikib ketishining oldi olinadi.

5. Parollarni saqlashda nega MD5 yoki SHA256 ishlatib bo'lmaydi?

Ko'plab dasturlashni yangi o'rganayotganlar bazaga parolni md5(password) qilib saqlash kifoya deb o'ylashadi. Bu o'ta xavfli xatodir! MD5 va hatto oddiy SHA256 algoritmlari juda tez hisoblanadi. Zamonaviy video kartalar (GPU) yordamida soniyasiga milliardlab variantlarni tekshirib, parolni bir necha daqiqada topish mumkin (Rainbow tables usulida).

Parollar uchun faqat sekin va maxsus moslashtirilgan xesh algoritmlaridan foydalanish shart: bcrypt, Argon2 yoki PBKDF2. Ular parolni xesh qilishda maxsus 'tuz' (salt) qo'shadi va hisoblash jarayonini ataylab sekinlashtiradi, bu esa bruteforce hujumlarini deyarli imkonsiz qiladi.

6. SQL Injection muammosini ORM to'liq hal qiladimi?

Ko'pchilik dasturchilar 'men Django ORM yoki Prisma ishlataman, demak loyihamda SQL Injection bo'lishi mumkin emas' deb xomxayolga berilishadi. Ha, ORM tayyorlangan parametrlashtirilgan so'rovlardan (prepared statements) foydalangani sababli odatiy SQL inyeksiyalarni to'liq bartaraf etadi.

Biroq, agar dasturchi xom SQL so'rovlaridan foydalanib, foydalanuvchi kiritgan ma'lumotni formatlash orqali ulasa, xavf yana qaytadi:

# XAVFLI KOD (SQL Injection xavfi bor):
query = f"SELECT * FROM users WHERE username = '{user_input}'"
User.objects.raw(query)

# XAVFSIZ KOD:
User.objects.raw("SELECT * FROM users WHERE username = %s", [user_input])

Hech qachon foydalanuvchi yuborgan qiymatlarni SQL qatoriga to'g'ridan-to'g'ri birlashtirmang!

7. HTTPS va SSL nima uchun shunchaki domen qulfi belgisi emas?

Ba'zilar HTTPS faqat to'lov kartalari yoki parollarni kiritish sahifalarida kerak deb hisoblashadi. Aslida esa butun veb-sayt HTTPS orqali ishlashi shart. HTTPS sizning foydalanuvchingiz va server orasidagi ma'lumotlarni shifrlaydi. Agar HTTPS bo'lmasa:

• Ommaviy Wi-Fi tarmoqlarida (masalan, qahvaxonalarda) oraliqdagi odam (Man-in-the-Middle) foydalanuvchilarning barcha ma'lumotlarini ochiq ko'ra oladi.
• Provayderlar yoki tajovuzkorlar saytingiz kodiga o'zlarining reklamalarini yoki zararli skriptlarini joylab qo'yishi mumkin.
• Google qidiruv tizimi HTTP saytlarning reytingini tushiradi va brauzerlar 'Xavfsiz emas' degan ogohlantirishni chiqaradi.

Bugungi kunda Let's Encrypt va Certbot yordamida har qanday Linux serverda bir necha daqiqa ichida mutlaqo bepul SSL sertifikatini o'rnatish mumkin.

Xulosa

Veb xavfsizligi — bu bir martalik o'rnatiladigan sozlama emas, balki doimiy odatdir. Ishonchli autentifikatsiya, to'g'ri sozlangan CORS, ma'lumotlarni doimiy tekshirish va zamonaviy xavfsizlik standartlariga amal qilish orqali siz loyihangizni va eng muhimi, foydalanuvchilaringiz ishonchini saqlab qolasiz.