Cookie, session va autentifikatsiya

HTTP tabiatan stateless: har bir so’rov alohida ko’riladi. Server bir so’rovni olganda, avvalgi so’rov aynan shu foydalanuvchidan kelganini o’z-o’zidan bilmaydi. Unda sayt login qilganingizni, savatdagi mahsulotlarni yoki til tanlovini qanday eslab qoladi? Buning uchun cookie, session va token kabi mexanizmlar ishlatiladi.

Cookie va session

Cookie — sayt brauzerda saqlashni so’rashi mumkin bo’lgan kichik nom=qiymat yozuvi. Server javobda Set-Cookie headerini yuboradi; brauzer keyingi mos so’rovlarda cookie’ni avtomatik qaytarishi mumkin.

Cookie’da quyidagi sozlamalar muhim:

Atribut	Vazifasi
Expires yoki Max-Age	Cookie qancha yashashini belgilaydi
Secure	Cookie faqat HTTPS orqali yuboriladi
HttpOnly	JavaScript cookie qiymatini o’qiy olmaydi
SameSite	Boshqa saytdan kelgan so’rovlarda yuborilishini cheklaydi
Path va Domain	Qaysi manzillarga cookie yuborilishini belgilaydi

Cookie ichiga parol, karta raqami yoki katta hajmdagi ma’lumot yozilmaydi. Ko’pincha u serverdagi sessionni topish uchun tasodifiy identifikator yoki imzolangan, cheklangan qiymat saqlaydi.

Cookie hajmi ham cheklangan — odatda 4 KB atrofida. Undan tashqari, cookie har mos so’rovda avtomatik yuboriladi, ya’ni har rasm va CSS fayli so’ralganda ham. Katta cookie butun saytni sekinlashtiradi.

SameSite atributining uch qiymati bor va ular amalda quyidagicha farq qiladi:

Qiymat	Xatti-harakat
Strict	Boshqa saytdan kelgan hech qanday so’rovga qo’shilmaydi
Lax	Oddiy havola bosilganda qo’shiladi, forma yuborilganda yo’q
None	Har doim qo’shiladi — Secure bilan birga bo’lishi shart

Ko’p ilova uchun Lax mos boshlanish nuqtasi: u CSRF himoyasini beradi, lekin tashqi havola orqali kirgan foydalanuvchini tizimdan chiqarib yubormaydi.

Session qanday ishlaydi

Session — foydalanuvchining bir nechta so’rov davomida saqlanadigan holati. Klassik server sessioni quyidagicha ishlaydi:

1. Foydalanuvchi login va parolini HTTPS orqali yuboradi.
2. Server ma’lumotni tekshiradi.
3. Server tasodifiy session identifikatori yaratadi va session ma’lumotini xavfsiz server saqloviga yozadi.
4. Identifikator HttpOnly, Secure cookie orqali brauzerga yuboriladi.
5. Keyingi so’rovlarda brauzer cookie’ni yuboradi.
6. Server identifikator orqali foydalanuvchini topib, session muddati va ruxsatlarini tekshiradi.

Token qayerda ishlatiladi

Ba’zi tizimlar server sessioni o’rniga yoki u bilan birga imzolangan token ishlatadi. Masalan, access token API so’rovining Authorization headerida yuborilishi mumkin. Token ichidagi ma’lumotni o’qish mumkin bo’lishi uning o’zgartirilishi mumkin degani emas — server imzoni tekshiradi.

Token “har doim cookie’dan yaxshiroq” emas. Qayerda saqlanishi, qanday yangilanishi, qanday bekor qilinishi va XSS/CSRF tahdidlariga qarshi qanday himoyalanishi arxitektura qaroridir. Boshlovchi uchun eng muhim narsa — tayyor frameworkning xavfsiz autentifikatsiya imkoniyatidan foydalanish va o’zicha kriptografiya yaratmaslik.

Ikki yondashuvni taqqoslash tanlovni osonlashtiradi:

Jihat	Server sessioni	Imzolangan token
Holat qayerda	Serverda saqlanadi	Tokenning o’zida
Bekor qilish	Oson — yozuvni o’chirish kifoya	Qiyin — muddat tugashini kutish kerak
Masshtablash	Umumiy saqlov kerak	Server holat saqlamaydi
Mos joyi	Odatiy web sayt	Mobil ilova, mikroservis, tashqi API

Eng muhim farq — bekor qilish. Foydalanuvchi parolini o’zgartirsa yoki hisobi bloklansa, server sessionini darhol o’chirish mumkin. Imzolangan token esa muddati tugagunga qadar amal qiladi. Shu sababli ko’p tizim ikkita token ishlatadi: qisqa muddatli access token (bir necha daqiqa) va uzoq muddatli refresh token, u orqali yangisi olinadi va kerak bo’lganda bekor qilinadi.

Autentifikatsiya va avtorizatsiya

Bu ikki atama ko’p aralashadi:

• autentifikatsiya — “siz kimsiz?” savoliga javob; masalan login;
• avtorizatsiya — “sizga bu amal mumkinmi?” savoliga javob; masalan faqat admin foydalanuvchini o’chira olishi.

Foydalanuvchi tizimga muvaffaqiyatli kirgan bo’lsa ham, barcha ma’lumotga ruxsat olgan bo’lmaydi. Backend har himoyalangan so’rovda avval session yoki tokenni, keyin aynan shu resurs uchun ruxsatni tekshiradi.

Ruxsatlarni tashkil qilishning ikki keng tarqalgan usuli bor. Rol asosida: foydalanuvchiga rol beriladi (admin, muharrir, oddiy) va har rol nima qila olishi belgilanadi. Egalik asosida: foydalanuvchi faqat o’zi yaratgan ma’lumotni o’zgartira oladi.

Amalda ko’p tizim ikkalasini birga ishlatadi: oddiy foydalanuvchi o’z buyurtmasini ko’radi, admin esa hammasini. Muhimi — bu qoidani bitta joyda yozish. Ruxsat tekshiruvi o’nlab route ichiga tarqalib ketsa, birortasini unutish ehtimoli oshadi.

Parol va sessiya boshqaruvi

Parol bilan ishlash

Login tizimining eng nozik qismi — parol. Uch qoida majburiy.

Parol hech qachon ochiq saqlanmaydi. Bazaga faqat xesh yoziladi va buning uchun maxsus algoritm (bcrypt, argon2, scrypt) ishlatiladi. Ular ataylab sekin ishlaydi, shuning uchun ularni ommaviy sinab ko’rish qiyin. md5 va sha1 bu vazifa uchun yaramaydi — ular juda tez.

Xato xabari ma’lumot bermasin. “Bunday email topilmadi” degan javob hujumchiga qaysi manzillar ro’yxatdan o’tganini aytadi. To’g’ri javob ikkala holatda bir xil: “Email yoki parol noto’g’ri”.

Urinishlar cheklanadi. Bir necha muvaffaqiyatsiz urinishdan keyin kechikish qo’shiladi yoki qo’shimcha tekshiruv so’raladi. Bu parolni ketma-ket sinab ko’rishni amalda imkonsiz qiladi.

Parolni tiklash oqimi ham xavfsiz bo’lishi kerak: tasodifiy, bir marta ishlatiladigan va qisqa muddatli havola yuboriladi. Havola ishlatilgach yoki muddati tugagach, u bekor bo’ladi.

Session muddati va logout

Session abadiy yashamasligi kerak. Ikki xil muddat qo’llaniladi: mutlaq muddat (masalan, 30 kundan keyin baribir tugaydi) va harakatsizlik muddati (masalan, 30 daqiqa hech narsa qilinmasa tugaydi). Bank yoki admin panel uchun qisqa muddat, oddiy sayt uchun uzunroq muddat mos keladi.

Logout paytida ikki ish bajariladi: cookie brauzerdan o’chiriladi va serverdagi session bekor qilinadi. Faqat cookie’ni o’chirish yetarli emas — session ID nusxasi qolgan bo’lsa, u hali ham ishlaydi.

Amaliy mashq

Har kuni ishlatadigan bitta saytga kiring va DevTools’ni oching. Application → Cookies bo’limida shu saytning cookie’larini ko’ring.

Uch savolga javob toping: qaysi cookie sessiyaga tegishli ko’rinadi, unda HttpOnly va Secure belgilanganmi, va SameSite qiymati nima? Keyin Network panelida istalgan so’rovni tanlab, Cookie headeri avtomatik yuborilganini ko’ring.

Bu mashq nazariy tushunchani real, ishlayotgan tizimda ko’rish imkonini beradi.

Qisqacha xulosa

• HTTP stateless; cookie va session so’rovlar orasida holatni bog’laydi.
• Cookie brauzerda saqlanadi va mos so’rovlarda serverga yuboriladi.
• Session ma’lumoti serverda, uning identifikatori cookie’da saqlanishi mumkin.
• Secure, HttpOnly va SameSite cookie xavfsizligining muhim atributlaridir.
• Autentifikatsiya foydalanuvchini taniydi, avtorizatsiya ruxsatni tekshiradi.
• Har bir himoyalangan backend route’ida ikkala tekshiruv ham zarur bo’lishi mumkin.

Keyingi darsda amaliy web xavfsizligi — o’rgangan xavfsizlik qoidalarini amaliy tekshiruvda qo’llaymiz.