CSRF mobil ishlab chiqishda: mohiyati, hujum turlari va himoya usullari

CSRF hujumi nima?

CSRF (Cross-Site Request Forgery) — bu tajovuzkor soxta so'rov yaratadigan va qurbonning brauzerini uni maqsadli serverga yuborishga majburlaydigan hujumdir. Server so'rovni bajaradi, chunki u foydalanuvchining joriy seansining haqiqiy cookie-credentials ma'lumotlarini oladi. Hujum mumkin, chunki brauzer so'rov qaysi sahifadan yuborilganidan qat'i nazar, maqsadli domen ga har bir so'rovga avtomatik ravishda cookie qo'shadi. Foydalanuvchi tajovuzkorning sahifasini ko'rmagan bo'lishi mumkin — zararli URL bilan yashirin <img>, <form> yoki <iframe> yuklash kifoya. CSRF to'g'ridan-to'g'ri ma'lumotlarni o'g'irlamaydi — hujum qurbon nomidan harakatlarni bajaradi (state-changing operations), masalan, pul o'tkazish, parolni o'zgartirish yoki hisobni o'chirish.

Qaysi operatsiyalar eng zaif?

CSRF hujumlari faqat holatni o'zgartiruvchi operatsiyalarga — yon ta'sirga ega GET so'rovlari, POST, PUT va DELETE ga qaratilgan. Masalan, shaxsiy hisobda elektron pochta manzilini o'zgartirish so'rovi: agar server kelib chiqishni tekshirmasdan so'rovni qabul qilsa, tajovuzkor o'z pochtasini almashtirishi va parolni tiklashni boshlashi mumkin. Hujum ayniqsa bank tizimlari, boshqaruv panellari va ijtimoiy tarmoqlar uchun xavflidir, bu erda bitta harakat jiddiy oqibatlarga olib keladi. Autentifikatsiya uchun cookie dan foydalanadigan mobil ilovalarning API lari ham qo'shimcha tekshirishlarni qo'llamasalar, CSRF ga moyil bo'ladi.

Kim xavf zonasida?

Hujumga autentifikatsiyasi cookie ga asoslangan va server so'rovning kelib chiqishini tekshirmaydigan har qanday veb ilovalar va API lar duchor bo'ladi. Veb formalar orqali avtorizatsiya uchun WebView dan foydalanadigan mobil ilovalar ham zaif: brauzer komponenti avtomatik ravishda cookie larni yuboradi va tajovuzkor fon yuklash orqali zararli so'rovni kiritishi mumkin. HackerOne (2025) ma'lumotlariga ko'ra, veb ilovalardagi barcha zaiflik hisobotlarining taxminan 12% i CSRF dan himoyaning yo'qligi bilan bog'liq.

CSRF ni nima xavfli qiladi?

CSRF ning asosiy xususiyati — qurbon uchun ko'rinmaslik. Foydalanuvchi hujum sodir bo'lganiga shubha qilmasligi mumkin: soxta so'rov fon rejimida bajariladi va ilova interfeysi buzilish belgilarini ko'rsatmaydi. CSRF ni aniqlashning yagona yo'li — server jurnallarini kuzatish yoki hisobdagi to'satdan o'zgarishlardir. Bundan tashqari, CSRF boshqa zaifliklar bilan oson birlashadi, masalan, XSS yoki ochiq qayta yo'naltirishlar, bu zararni bir necha barobar oshiradi.

CSRF hujumi qanday ishlaydi?

CSRF hujumi uchta majburiy shartdan iborat: qurbon maqsadli saytda avtorizatsiyalangan, server cookie autentifikatsiyasidan foydalanadi va tajovuzkorning so'rovi action URL ga yo'naltirilgan. Tajovuzkor HTML sahifasini forma, skript yoki src atributi maqsadli URL ni ko'rsatadigan rasm bilan yaratadi. Qurbonning brauzeri bu sahifani yuklaydi va avtomatik ravishda so'rovni joriy seans cookie si bilan birga serverga yuboradi. Server haqiqiy cookie larni oladi, so'rov manbasini tekshirmaydi va operatsiyani bajaradi.

<!-- Yashirin forma orqali CSRF-hujum misoli -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

Sahifa yuklangandan so'ng, skript darhol formani yuboradi. Brauzer foydalanuvchining seans cookie sini bank.example.com ga POST so'roviga qo'shadi. Bank serveri cookie ni tekshiradi, foydalanuvchi autentifikatsiyalanganligiga ishonch hosil qiladi va tajovuzkorning hisobiga pul o'tkazmasini amalga oshiradi. Qurbon bo'sh yoki qonuniy sahifani ko'radi, pul esa allaqachon yechib olingan.

Brauzerning CSRF dagi roli

HTTP protokolining asosiy xususiyati — so'rovning ichki manba tekshiruvining yo'qligi. Brauzer, agar so'rov domeni cookie domeniga mos kelsa, so'rovga cookie qo'shadi. Tajovuzkor cookie tarkibini bilishi shart emas — brauzer buni avtomatik qiladi. Same-origin policy CSRF dan himoya qilmaydi, chunki hujum serverga qaratilgan, javobni o'qishga emas. CORS kabi mexanizmlar ham ojiz: CSRF so'rovlari zarar etkazish uchun odatda javobni o'qishni talab qilmaydi.

CSRF hujumlarining asosiy turlari

CSRF hujumlari zararli so'rovni yetkazib berish usuliga ko'ra tasniflanadi. Har bir tur so'rovni yuborish uchun turli xil HTML elementidan foydalanadi, ammo barchasi brauzer tomonidan cookie larning avtomatik yuborilishiga tayanadi. Usulni tanlash tajovuzkorning maqsadlariga bog'liq: GET-based hujumlar kamroq kod talab qiladi, POST-based ba'zi himoyalarni ishonchliroq chetlab o'tadi va XMLHttpRequest-based sarlavhalarni manipulyatsiya qilish imkonini beradi.

GET-based CSRF

Eng oddiy usul: tajovuzkor sahifaga so'rov parametrlari bo'lgan URL bilan <img> joylashtiradi. Brauzer rasmni yuklaydi va serverga GET so'rovini yuboradi. Masalan, <img src="https://api.example.com/delete?postId=123" /> agar server DELETE ni GET orqali qayta ishlasa, yozuvni o'chiradi. Aniq xavfga qaramay, ba'zi API lar hali ham o'chirish yoki yangilash operatsiyalari uchun GET dan foydalanadi.

POST-based CSRF

Agar server faqat POST so'rovlarini qabul qilsa, tajovuzkor POST usuli bilan yashirin forma yaratadi va uni JavaScript orqali avtomatik yuboradi. Forma ekranda ko'rsatilmaydi (barcha <input> type="hidden"), va autofocus + .submit() foydalanuvchi bosmasdan ishlaydi. Agar server Content-Type sarlavhasini tekshirsa, POST-based hujumlar ishlamaydi, ammo ko'pchilik API lar standart application/x-www-form-urlencoded ni qabul qiladi.

XHR-based CSRF (CORS bilan)

XMLHttpRequest yoki Fetch API ixtiyoriy sarlavhalar bilan so'rovlar yuborish imkonini beradi. Agar server CORS ni juda keng sozlagan bo'lsa (Access-Control-Allow-Origin: *), tajovuzkor istalgan so'rovni yuborishi va javobni o'qishi mumkin. Biroq, CSRF hujumi uchun javobni o'qish shart emas — harakatni bajarish kifoya. Zamonaviy brauzerlar nostandart so'rovlardan oldin OPTIONS preflight so'rovini yuboradi, bu server to'g'ri sozlangan bo'lsa, XHR-based CSRF ni bloklashi mumkin.

Mobil ilovalarda CSRF

Mobil ilovalar CSRF ga veb saytlardan kamroq moyil, chunki mahalliy ilovalar kamdan-kam cookie autentifikatsiyasidan foydalanadi. Buning o'rniga, mobil API lar ko'pincha Authorization sarlavhasida tokenlarni (Bearer tokenlari, JWT) qo'llaydi. Biroq, CSRF hujumi mumkin bo'lgan stsenariylar mavjud: veb kirish bilan WebView, gibrid ilovalar va cookie-ga asoslangan seansli API lar. TechCrunch (2025) ma'lumotlariga ko'ra, mobil ilovalarning taxminan 18% ommaviy API lari hali ham seans cookie larini qo'llab-quvvatlaydi.

WebView orqali CSRF

Ko'pgina ilovalar veb sahifalarni WebView da ochadi — OAuth orqali avtorizatsiya, to'lov formalari, tarkibni ko'rish. WebView — bu ilova ichidagi to'liq brauzer bo'lib, u seans cookie larini saqlaydi. Agar tajovuzkor o'z URL sini WebView da yuklash yo'lini topsa (ochiq qayta yo'naltirish yoki Deep Link orqali), oddiy brauzerdagi kabi CSRF hujumini amalga oshirishi mumkin. Himoya — muhim operatsiyalar uchun WebView o'rniga Chrome Custom Tabs yoki SFSafariViewController dan foydalanish.

JWT autentifikatsiyasi bilan API larda CSRF

JWT tokenlari odatda localStorage da yoki ilova xotirasida saqlanadi va avtomatik yuborilmaydi — dasturchi har bir so'rovga Authorization sarlavhasini aniq qo'shadi. Bu klassik CSRF hujumini imkonsiz qiladi. Biroq, agar ilova JWT ni cookie da saqlasa (kamdan-kam, lekin uchraydi), xavf qaytadi. Qo'shimcha himoya — JWT ni azp yoki aud claim i orqali so'rovning ma'lum bir origin iga bog'lash, bu tokenni boshqa domenda ishlatilishining oldini oladi.

// Express da CSRF tokenining server tomonida tekshirish namunasi
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// Kirishda CSRF tokenini yaratish
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

CSRF dan himoya usullari

CSRF dan zamonaviy himoya uch darajaga asoslanadi: server CSRF tokenlari, cookie uchun SameSite atributi va Origin sarlavhasini tekshirish. Bu usullarning kombinatsiyasi UX ga sezilarli ta'sir ko'rsatmasdan CSRF hujumlarining 99% dan himoyani ta'minlaydi. Muayyan yondashuvni tanlash ilova arxitekturasiga bog'liq: veb sayt uchun SameSite=Lax yetarli, mobil ilova API si sarlavhalarda tokenlarni talab qiladi.

CSRF tokenlari (sinxronizator)

Standart usul: server noyob token yaratadi, uni foydalanuvchi seansiga bog'laydi va mijozga uzatadi. Mijoz holatni o'zgartiruvchi har bir so'rovga tokenni qo'shadi (formaning yashirin maydonida yoki X-CSRF-Token sarlavhasida). Server olingan tokenni seansda saqlangan bilan solishtiradi. Token kriptografik jihatdan xavfsiz, tasodifiy, kamida 32 bayt uzunlikda bo'lishi va har bir seans yoki operatsiyada o'zgarishi kerak. Tokenning ishlash muddati — bir necha soatdan oshmasligi kerak.

SameSite Cookie

Cookie uchun SameSite atributi kross-domen so'rovlarida cookie jo'natilishini cheklaydi. Lax qiymati faqat yuqori darajadagi navigatsiya GET so'rovlari uchun cookie jo'natishga ruxsat beradi — bu ko'pchilik saytlar uchun yetarli. Strict barcha kross-domen so'rovlari, jumladan navigatsiya uchun cookie ni bloklaydi: foydalanuvchi boshqa saytdan o'tishda qayta kirishi kerak bo'ladi. Chrome Platform Status (2026) ma'lumotlariga ko'ra, SameSite=Lax barcha zamonaviy brauzerlarda sukut bo'yicha yoqilgan, bu CSRF hujumlari sonini 67% ga kamaytirdi.

Origin va Referer tekshiruvi

Server kiruvchi so'rovning Origin yoki Referer sarlavhalarini tekshirishi mumkin. Agar so'rov boshqa domendan kelgan bo'lsa — bloklanadi. Origin Referer dan ishonchliroq, chunki u har doim POST so'rovlarida mavjud va brauzer siyosatlari bilan o'chirilmaydi. Amalga oshirish: ruxsat etilgan originlarning oq ro'yxati, sarlavhaning joriy qiymati bilan solishtirish. Usul samarali, ammo Origin sarlavhalari bo'lishi mumkin bo'lmagan yoki soxtalashtirilishi mumkin bo'lgan mobil ilovalar bilan murakkab.

// Spring Boot da CSRF tokenini tekshirish namunasi
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit Cookie

Serverda token saqlashni talab qilmaydigan usul: server tasodifiy qiymat bilan cookie o'rnatadi, mijoz cookie dan qiymatni o'qiydi va uni sarlavhada yoki so'rov tanasida qaytaradi. Server ikkala qiymatni solishtiradi. Agar tajovuzkor cookie ni o'qiy olmasa (Same-origin policy), tokeni soxtalashtira olmaydi. Usul sinxronizatordan osonroq amalga oshiriladi, ammo cookie ni tutib olishdan himoya qilish uchun HTTPS talab qiladi.

• CSRF tokenlari — oltin standart: ishonchli, vaqt sinovidan o'tgan, barcha freymvorklarda qo'llab-quvvatlanadi
• SameSite=Lax — veb ilovalar uchun minimal himoya: bepul, avtomatik, kod talab qilmaydi
• Origin tekshiruvi — qo'shimcha daraja: tokenni tekshirishdan oldin hujumlarni bloklaydi
• Double Submit — server tomoni seanslari bo'lmagan REST API uchun: HTTPS da samarali
• Maxsus sarlavhalar — X-Requested-With: XMLHttpRequest oddiy CSRF formalarini bloklaydi

CSRF va XSS o'rtasidagi farq

CSRF va XSS — ko'pincha aralashtiriladigan turli xil hujum turlari. CSRF serverning foydalanuvchi brauzeriga bo'lgan ishonchini ekspluatatsiya qiladi: server tajovuzkorning buyrug'ini bajaradi, chunki so'rov haqiqiy cookie bilan keladi. XSS brauzerning server tarkibiga bo'lgan ishonchini ekspluatatsiya qiladi: brauzer tajovuzkor tomonidan sahifaga kiritilgan skriptni bajaradi. CSRF maqsadli saytga kod kiritishni talab qilmaydi — boshqa domendan so'rov yuborish kifoya. XSS esa, aksincha, sahifaning HTML kodiga o'z JavaScript ini kiritish yo'lini topishni talab qiladi. Bundan tashqari, XSS CSRF himoyasini chetlab o'tishi mumkin: kiritilgan skript sahifadan CSRF tokenini o'qiydi va uni so'rov bilan birga yuboradi.

CSRF va XSS o'rtasidagi farqni tushunish ko'p darajali himoyani qurish uchun juda muhimdir. CSRF tokenlari XSS dan himoya qilmaydi, CSP (Content Security Policy) esa CSRF dan himoya qilmaydi. Faqat usullarning kombinatsiyasi ilovaning ikkala hujum turidan xavfsizligini ta'minlaydi. WebView bilan mobil ilovalarda xavflar ikki baravar ortadi, shuning uchun dasturchilarga API so'rovlari uchun kamida CSRF tokenlari va veb tarkib uchun Content Security Policy ni qo'llash tavsiya etiladi.