CSRF mobil inkişafda: mahiyyəti, hücum növləri və qorunma üsulları

CSRF hücumu nədir?

CSRF (Cross-Site Request Forgery) — təcavüzkərin saxta sorğu yaratdığı və qurbanın brauzerini onu hədəf serverə göndərməyə məcbur etdiyi hücumdur. Server sorğu yerinə yetirir, çünki istifadəçinin cari sessiyasının etibarlı cookie-credentials məlumatlarını alır. Hücum mümkündür, çünki brauzer sorğun hansı səhifədən göndərildiyindən asılı olmayaraq, hədəf domenə göndərilən hər sorğuya avtomatik olaraq cookie əlavə edir. İstifadəçi təcavüzkərin səhifəsini görməmiş də ola bilər — zərərli URL ilə gizli <img>, <form> və ya <iframe> yükləmək kifayətdir. CSRF birbaşa məlumat oğurlanmır — hücum qurbanın adından əməliyyatlar yerinə yetirir (state-changing operations), məsələn, pul köçürmə, şifrəni dəyişmə və ya hesabı silmə.

Hansı əməliyyatlar daha çox həssasdır?

CSRF hücumları yalnız vəziyyəti dəyişən əməliyyatlara yönəlir — yan təsirləri olan GET sorğulari, POST, PUT və DELETE. Məsələn, şəxsi kabinetdə e-poçt ünvanını dəyişmə sorğu: əgər server mənşəyi yoxlamadan sorğu qəbul edərsə, təcavüzkər öz poçtunu əvəz edə və şifrənin sıfırlanmasını başlada bilər. Hücum xüsusilə bank sistemləri, inzibatçı panelləri və sosial şəbəkələr üçün təhlükəlidir, burada bir əməliyyat ciddi nəticələrə səbəb ola bilər. Autentifikasiya üçün cookie istifadə edən mobil tətbiqlərin API-ləri də əlavə yoxlamalar tətbiq etmədikdə CSRF-yə məruz qalır.

Kim risk zonasındadır?

Hücuma autentifikasiyası cookiyə əsaslanan və server sorğunun mənşəyini yoxlamayan istənilən veb tətbiq və API məruz qalır. Veb formalar vasitəsilə səlahiyyət vermək üçün WebView istifadə edən mobil tətbiqlər də həssasdır: brauzer komponenti avtomatik olaraq cookie göndərir və təcavüzkər fon yükləmə vasitəsilə zərərli sorğu daxil edə bilər. HackerOne (2025) məlumatlarına görə, veb tətbiqlərdəki bütün zəiflik hesabatlarının təxminən 12% -i CSRF-dən qorunmanın olmaması ilə bağlıdır.

CSRF-ni nə təhlükəli edir?

CSRF-nin əsas xüsusiyyəti qurban üçün görünməz olmasıdır. İstifadəçi hücumun baş verdiyindən şübhələnməyə də bilər: saxta sorğu fon rejimində yerinə yetirilir və tətbiqin interfeysi sındırma əlamətləri göstərmir. CSRF-ni aşkarlamağın yeganə yolu server jurnallarını izləmək və ya hesabda qəfil dəyişikliklərdir. Bundan əlavə, CSRF asanlıqla birləşdirilir XSS və ya açıq yönləndirmələr kimi digər zəifliklərlə, bu da zərəri dəfələrlə artırır.

CSRF hücumu necə işləyir?

CSRF hücumu üç məcburi şərtdən ibarətdir: qurban hədəf saytda səlahiyyətlidir, server cookie autentifikasiyasından istifadə edir və təcavüzkərin sorğu action-ÇURL-ə yönəldilir. Təcavüzkər formanın, skriptin və ya şəklin olduğu HTML səhifəsi yaradır, onun src atributu hədəf URL-i göstərir. Qurbanın brauzeri bu səhifəni yükləyir və avtomatik olaraq cari sessiyanın cookie ilə birlikdə serverə sorğu göndərir. Server etibarlı cookie alır, sorğun mənbəyini yoxlamır və əməliyyatı yerinə yetirir.

<!-- Gizli forma vasitəsilə CSRF hücum nümunəsi -->
<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>

Səhifə yükləndikdən sonra skript dərhal formanı göndərir. Brauzer bank.example.com ünvanına POST sorğuna istifadəçinin sessiya cookie əlavə edir. Bankın serveri cookieni yoxlayır, istifadəçinin autentifikasiya olunduğuna əmin olur və təcavüzkərin hesabına pul köçürməni həyata keçirir. Qurban boş və ya qanuni səhifə görür, pul isə artıq silinmişdir.

Brauzerin CSRF-də rolu

HTTP protokolunun əsas xüsusiyyəti sorğun mənbəsinin daxili yoxlanılmamasıdır. Brauzer, sorğun domeni cookinin domeni ilə üst-üstə düşɔrsə, sorğuya cookie əlavə edir. Təcavüzkər cookinin məzmununu bilməlidir — brauzer bunu avtomatik edir. Same-origin policy CSRF-dən qorumur, çünki hücum serverə yönəlib, cavabı oxumağa deyil. CORS kimi mexanizmlər də acizdir: CSRF sorğuları zərər vurmaq üçün adətən cavabın oxunmasını tələb etmir.

CSRF hücumlarının əsas növləri

CSRF hücumları zərərli sorğun çatdırılma üsuluna görə təsnif edilir. Hər növ sorğu göndərmək üçün müxtəlif HTML elementi istifadə edir, lakin hamısı brauzer tərəfindən cookie-nin avtomatik göndərilməsinə əsaslanır. Metodun seçimi təcavüzkərin məqsədlərindən asılıdır: GET-based hücumlar daha az kod tələb edir, POST-based bəzi qorumaları daha etibarlı şəkildə yan keçir, XMLHttpRequest-based isə başlıqları manipulyasiya etməyə imkan verir.

GET-based CSRF

Ən sadə üsul: təcavüzkər səhifəyə sorğu parametrləri olan URL ilə <img> yerləşdirir. Brauzer şəkli yükləyir və serverə GET sorğu göndərir. Məsələn, <img src="https://api.example.com/delete?postId=123" /> əgər server DELETE sorğunu GET vasitəsilə emal edərsə, yazını silir. Açıq təhlükəyə baxmayaraq, bəzi API-lər hələ də silmə və ya yeniləmə əməliyyatları üçün GET-dən istifadə edir.

POST-based CSRF

Əgər server yalnız POST sorğularını qəbul edərsə, təcavüzkər POST metodu ilə gizli forma yaradır və onu JavaScript vasitəsilə avtomatik göndərir. Forma ekranda göstərilmir (bütün <input> type="hidden"), və autofocus + .submit() istifadəçinin klik etməsi olmadan işləyir. Əgər server Content-Type başlığını yoxlayarsa, POST-based hücumlar işləmir, lakin əksər API standart application/x-www-form-urlencoded qəbul edir.

XHR-based CSRF (CORS ilə)

XMLHttpRequest və ya Fetch API ixtiyari başlıqlarla sorğular göndərməyə imkan verir. Əgər server CORS çox geniş konfiqurasiya edərsə (Access-Control-Allow-Origin: *), təcavüzkər istənilən sorğu göndərə və cavabı oxuya bilər. Lakin CSRF hücumu üçün cavabı oxumaq məcburi deyil — əməliyyatı yerinə yetirmək kifayətdir. Müasir brauzerlər qeyri-standart sorğulardan əvvəl OPTIONS preflight sorğu göndərir, bu da server düzgün konfiqurasiya edilərsə, XHR-based CSRF-ni bloklaya bilər.

Mobil tətbiqlərdə CSRF

Mobil tətbiqlər CSRF-yə veb saytlardan daha az həssasdır, çünki yerli tətbiqlər nadir hallarda cookie autentifikasiyasından istifadə edir. Bunun əvəzinə mobil API-lər daha çox Authorization başlığında tokenlər (Bearer-tokenlər, JWT) tətbiq edir. Lakin CSRF hücumunun mümkün olduğu ssenarilər var: veb girişi olan WebView, hibrid tətbiqlər və cookie-based sessiyaları olan API. TechCrunch (2025) məlumatlarına görə, mobil tətbiqlərin təxminən 18% ictimai API-ləri hələ də sessiya cookie-lərini dəstəkləyir.

WebView vasitəsilə CSRF

Bir çox tətbiq veb səhifələri WebView-də açır — OAuth vasitəsilə autentifikasiya, ödəniş formaları, məzmun baxışı. WebView tətbiq daxilində sessiya cookie-lərini saxlayan tam hüquqlu brauzerdir. Əgər təcavüzkər öz URL-ni WebView-də yükləmək üçün bir yol taparsa (açıq yönləndirmə və ya Deep Link vasitəsilə), adi brauzerdə olduğu kimi CSRF hücumu həyata keçirə bilər. Qorunma — kritik əməliyyatlar üçün WebView əvəzinə Chrome Custom Tabs və ya SFSafariViewController istifadə etmək.

JWT autentifikasiyası olan API-lərdə CSRF

JWT tokenləri adətən localStorage-də və ya tətbiqin yaddaşında saxlanılır və avtomatik göndərilmir — proqramçı hər sorğuya açıq şəkildə Authorization başlığı əlavə edir. Bu, klassik CSRF hücumunu qeyri-mümkün edir. Lakin tətbiq JWT-ni cookie-də saxlayarsa (nadir, lakin rast gəlinir), risk qayıdır. Əlavə qorunma — JWT-ni azp və ya aud claim-i vasitəsilə xüsusi sorğu mənşəyinə bağlamaq, bu da tokenin başqa domenində istifadəsinin qarşısını alır.

// Express-də CSRF tokeninin server tərəfi yoxlanması nümunəsi
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();
};

// Girişdə CSRF tokeninin yaradılması
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

CSRF-dən qorunma üsulları

Müasir CSRF-dən qorunma üç səviyyəyə əsaslanır: server CSRF tokenləri, cookie üçün SameSite atributu və Origin başlığının yoxlanması. Bu metodların birləşməsi UX-ə əhəmiyyətli təsir etmədən CSRF hücumlarının 99% -dən qorunma təmin edir. Konkret yanaşmanın seçimi tətbiqin arxitekturasından asılıdır: veb sayt üçün SameSite=Lax kifayətdir, mobil tətbiqin API-si başlıqlarda tokenlər tələb edir.

CSRF tokenləri (sinxronizator)

Standart üsul: server unikal token yaradır, onu istifadəçinin sessiyasına bağlayır və müştəriyə ötürür. Müştəri vəziyyəti dəyişən hər sorğuya token daxil edir (formanın gizli sahəsində və ya X-CSRF-Token başlığında). Server alınan tokeni sessiyada saxlanılanla müqayisə edir. Token kriptoqrafik cəhətdən təhlükəsiz, təsadüfi, ən azı 32 bayt uzunluğunda olmalı və hər sessiya və ya əməliyyatda dəyişməlidir. Tokenin ömrü — bir neçə saatdan çox olmamalıdır.

SameSite Cookie

Cookie üçün SameSite atributu kross-domen sorğularında cookie göndərilməsini məhdudlaşdırır. Lax dəyəri yalnız yuxarı səviyyəli naviqasiya GET sorğuları üçün cookie göndərilməsinə icazə verir — bu əksər saytlar üçün kifayətdir. Strict bütün kross-domen sorğuları, o cümlədən naviqasiya üçün cookie-ni bloklayır: istifadəçi başqa saytdan keçid edərkən yenidən daxil olmalı olacaq. Chrome Platform Status (2026) məlumatlarına görə, SameSite=Lax bütün müasir brauzerlərdə defolt olaraq aktivdir ki, bu da CSRF hücumlarının sayını 67% azaldıb.

Origin və Referer yoxlanması

Server daxil olan sorğun Origin və ya Referer başlıqlarını yoxlaya bilər. Əgər sorğu başqa domendən gəlibsə — bloklanır. Origin Referer-dən daha etibarlıdır, çünki həmişə POST sorğularında mövcuddur və brauzer siyasətləri ilə söndürülmür. Tətbiq: icazə verilən originlərin ağ siyahısı, başlığın cari dəyəri ilə müqayisə. Metod effektivdir, lakin Origin başlıqlarının olmaya və ya saxtalaşdırıla biləcəyi mobil tətbiqlərlə mürəkkəbdir.

// Spring Boot-da CSRF tokeninin yoxlanması nümunəsi
@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

Serverdə token saxlamağı tələb etməyən üsul: server təsadüfi dəyərlə cookie təyin edir, müştəri cookie-dən dəyəri oxuyur və onu başlıqda və ya sorğu gövdəsində geri göndərir. Server hər iki dəyəri müqayisə edir. Əgər təcavüzkər cookie-ni oxuya bilmirsə (Same-origin policy), tokeni saxtalaşdıra bilməyəcək. Metod sinxronizatordan daha asan tətbiq olunur, lakin cookie-nin kəsilməsindən qorunmaq üçün HTTPS tələb edir.

• CSRF tokenləri — qızıl standart: etibarlı, zamanla sınaqdan keçmiş, bütün freymvorklarda dəstəklənir
• SameSite=Lax — veb tətbiqlər üçün minimal qorunma: pulsuz, avtomatik, kod tələb etmir
• Origin yoxlanması — əlavə səviyyə: token yoxlanmazdan əvvəl hücumları bloklayır
• Double Submit — server tərəfi sessiyaları olmayan REST API üçün: HTTPS-də effektivdir
• Xüsusi başlıqlar — X-Requested-With: XMLHttpRequest sadə CSRF formalarını bloklayır

CSRF və XSS arasındakı fərq

CSRF və XSS tez-tez qarışdırılan müxtəlif hücum növləridir. CSRF serverin istifadəçinin brauzerinə olan etibarından istifadə edir: server təcavüzkərin əmrini yerinə yetirir, çünki sorğu etibarlı cookie ilə gəlir. XSS brauzerin serverin məzmununa olan etibarından istifadə edir: brauzer təcavüzkər tərəfindən səhifəyə daxil edilmiş skripti yerinə yetirir. CSRF hədəf saytda kod daxil etməyi tələb etmir — başqa domendən sorğu göndərmək kifayətdir. XSS isə əksinə, səhifənin HTML koduna öz JavaScriptini daxil etməyin yolunu tapmağı tələb edir. Bundan əlavə, XSS CSRF qorumasını yan keçə bilər: daxil edilmiş skript səhifədən CSRF tokenini oxuyur və onu sorğu ilə birlikdə göndərir.

CSRF və XSS arasındakı fərqi başa düşmək çoxsəviyyəli qorunma qurmaq üçün kritik əhəmiyyət daşıyır. CSRF tokenləri XSS-dən qorumur, CSP (Content Security Policy) isə CSRF-dən qorumur. Yalnız metodların birləşməsi tətbiqin hər iki hücum növündən təhlükəsizliyini təmin edir. WebView ilə mobil tətbiqlərdə risklər ikiqat artır, buna görə proqramçılara API sorğuları üçün ən azı CSRF tokenləri və veb məzmun üçün Content Security Policy tətbiq etmək tövsiyə olunur.