CSRF
CSRF nədir?
CSRF (Cross-site request forgery - Saytlar arası sorğu saxtakarlığı), bir təcavüzkarın istifadəçiləri icra etmək istəmədiyi əməliyyatları icra etməsinə sövq etməsinə imkan verən veb təhlükəsizlik boşluğudur. Bu, təcavüzkarın fərqli veb saytların bir-birilə əlaqə qurmasını önləmək üçün dizayn edilmiş same origin siyasətini qismən dəf etməsinə imkan verir.
CSRF hücumunun təsiri
Uğurlu bir CSRF hücumunda təcavüzkar, qurban istifadəçinin onun razılığı olmadan bir əməliyyat həyata keçirməsinə səbəb olur. Məsələn, bir hesabın e-poçt ünvanını və parolunu dəyişdirmək və ya pul transferi etmək kimi əməliyyatları nümunə gətirmək olar. Əməliyyatın xarakterindən asılı olaraq təcavüzkar, istifadəçinin hesabı üzərində tam nəzarətə sahib ola bilər.
CSRF necə işləyir?
Bir CSRF hücumunun uğurlu olması üçün üç mühüm şərt mövcud olmalıdır:
Əlaqəli bir əməliyyat: Tətbiq daxilində, təcavüzkarın təhrik etməsinə səbəb olacaq bir əməliyyat olmalıdır. Bu, (digər istifadəçilər üçün icazələrin dəyişdirilməsi kimi) imtiyazlı bir əməliyyat və ya (istifadəçinin öz parolunu dəyişdirməsi kimi) istifadəçiyə xas bir data üzərində əməliyyat ola bilər.
Cookie əsaslı seans emalı: Əməliyyatı icra etmək, bir və ya bir neçə HTTP sorğusunu göndərməyi ehtiva edir və tətbiq, sorğuları göndərən istifadəçini müəyyənləşdirmək üçün seans cookie-lərinə güvənir. Seansları təqib etmək və ya istifadəçi sorğularını doğrulamaq üçün başqa bir mexanizm yoxdur.
Təxmin edilə bilməyən sorğu parametrləri yoxdur: Bir CSRF hücumunun uğurlu olması üçün, təcavüzkarın göndərəcəyi sorğudakı bütün parametrləri əvvəlcədən təxmin edə bilməsi və ya bilməsi lazımdır. Əgər təcavüzkarın təxmin edə bilməyəcəyi, ya da bilmədiyi bir məlumat lazımdırsa, hücum uğursuz olacaq. Məsələn, bir istifadəçi parolunu dəyişdirmək üçün mövcud parolunu daxil etməlidirsə, təcavüzkar bu mövcud parolu bilməsə, hücum uğursuz olacaq. Belə halda, sistem CSRF-ə qarşı mühafizə edilmiş olur. Nəticə etibarilə, CSRF hücumuna qarşı həssas bir sistemdə, təcavüzkarın göndərəcəyi sorğudakı bütün parametrlərin təxmin edilə bilən və sabit olması lazımdır.
Məsələn, fərz edək ki, bir tətbiqdə istifaədəçinin e-poçt ünvanını dəyişdirməsinə icazə verən bir funksiya var. İstifadəçi bu əməliyyatı icra etdikdə, aşağıdakı kimi bir sorğu gedir:
Bu, CSRF üçün tələb olunan şərtlərə cavab verir:
Bir istifadəçinin öz hesabındakı e-poçtu dəyişdirmə prosesi, təcavüzkarın diqqətini cəlb edir. Çünki təcavüzkar, yeni bir parol sıfırlama sorğusu ilə istifadəçinin hesabını ələ keçirə bilər.
Tətbiq, yalnız seans cookie-sinə güvənir. Bu, istifadəçinin öz kimliyini müəyyən etməsi üçün tək mexanizmdir. CSRF token və ya başqa bir doğrulama üsulu istifadə edilmir.
Sorğu zamanı istifadə edilən parametrlər, təcavüzkar tərəfindən asanlıqda təxmin edilə bilir. Təcavüzkar, bu parametrləri istifadə edərək saxta bir sorğu yarada bilər.
Bu şərtləri cavab verildikdə, təcavüzkar aşağıdakı HTML kodunu ehtiva edən bir veb sayt yarada bilər:
Əgər istifadəçi, təcavüzkarın veb səhifəsini ziyarət etsə, aşağıdakılar baş verəcək:
Təcavüzkarın səhifəsi, CSRF boşluğu olan səhifəyə HTTP sorğusu göndərəcək.
Əgər istifadəçi, daha əvvəl CSRF boşluğuna sahib veb saytda hesabına giriş edibsə, brauzer seans cooke-sini avtomatik olaraq sorğuya daxil edəcək (samesite cookie-lərin istifadə edilməyini fərz edirik).
CSRF boşluğu olan veb sayt, sorğunu normal olaraq emal edəcək, sorğunun zərərçəkən istifadəçi tərəfindən edildiyini nəzərə alacaq və e-poçt ünvanını dəyişdirəcək.
CSRF, adətən cookie-based session handling (yəni çərəz əsaslı seans idarəsi) konteksində izah olunur, ancaq bu hallarda da meydana gələ bilər:
HTTP Basic Authentication: Əgər tətbiq, edilən hər sorğuya istifadəçi kimlik məlumatlarını avtomatik daxil edirsə, bu məlumatlar CSRF hücumlarına qarşı həssas ola bilər.
Certificate-based Authentication: İstifadəçinin doğrulanması üçün sertifikatlar istifadə edilirsə və bu məlumatlar avtomatik əlavə edilirsə, bu da CSRF-ə yol aça bilər.
Yəni, CSRF sadəcə cookie-lərlə məhdudlaşmır. İstifadəçi məlumatlarının avtomatik olaraq əlavə edildiyi hallarda da üzə çıxa bilir.
CSRF exploit necə həyata keçilir?
Saytlar arası sorğu saxtakarlığı üçün çatdırılma mexanizmləri, demək olar ki, reflected XSS ilə eynidir. Tipik olaraq, haker zərərli HTML-i, nəzarət etdiyi bir veb sayta yerləşdirir və qurbanı həmin veb saytı ziyarət etməyə təşviq edir. Bu, istifadəçiyə bir e-poçt və ya sosial media mesajı vasitəsilə veb sayta yönləndirən bir keçid göndərilərək həyata keçirilir. Və yaxud, həmin keçid rəy bölməsinə yerləşdirilərək, istifadəçilərin həmin veb saytı ziyarət etməsi gözlənilir.
Unutmayın ki, sadə CSRF hücumu, hədəf veb saytdakı bir URL-ni istifadə edərək həyata keçirilir. Bu hücumlar GET metodu ilə icra olunur və bütün hücum, tək bir URL daxilində saxlana bilər. Yəni, hakerin başqa bir saytı və ya mürəkkəb bir üsul istifadə etməsinə ehtiyac qalmır. Məsələn, əgər bir veb saytda e-poçt dəyişdirmə prosesi sadəcə GET metodu ilə mümkündürsə, haker, hədəf şəxsin e-poçt ünvanını hakerin istədiyi ünvana dəyişdirə bilən bir URL hazırlayır və onu qurbana göndərir. Əgər, qurban bu URL-yə klikləsə, onun fərqində olmadan e-poçt ünvanı dəyişir. Aşağıdakı kimi zərərli URL yaradıla bilər:
Bunu önləmək üçün GET metodu ilə kritik əməliyyat edilməməlidir. Bunun əvəzinə POST kimi daha güvənli metodlar istifadə edilməlidir. Ya da CSRF tokenlər istifadə oluna bilər.
CSRF-ə qarşı geniş yayılmış müdafiə üsulları
CSRF boşluqlarını müvəffəqiyyətlə tapmaq və exploit etmək, adətən hədəf veb sayt, qurbanın brauzeri və ya hər ikisi tərəfindən istifadə edilən anti-CSRF tədbirlərini bypass etməyi ehtiva edir. Üzləşəcəyiniz ən geniş yayılmış müdafiə üsulları bunlardır:
CSRF tokens: Bir CSRF tokeni, server-side tətbiq tərəfindən yaradılan və client ilə paylaşılan unikal, secret və təxmin edilə bilməyən bir dəyərdir. Bir form göndərmək kimi həssas bir əməliyyatı icra etməyə çalışarkən, client, sorğuya doğru CSRF tokenini daxil etməlidir. Bu, hakerin, qurbanın adından yararlı bir sorğu yaratmasını olduqca çətinləşdirir.
SameSite cookies: SameSite, brauzerlərin təhlükəsizliyini artırmaq üçün istifadə edilən bir mexanizmdir. Bu mexanizm, bir veb saytın çərəzlərinin, başqa bir veb saytdan gələn sorğularda istifadə edilib-edilməyəcəyini müəyyən edir. Məsələn, bir istifadəçi, bir veb saytda hesabına daxil olmalıdırsa (authenticated session), bu seansı doğrulamaq üçün çərəzlər lazımdır. Əgər, SameSite mexanizmi, düzgün tətbiq edilibsə, bu çərəzlər başqa bir veb saytdan gələn sorğularda istifadə edilməyəcək. Chrome, 2021-ci ildən etibarən Lax SameSite məhdudiyyətlərini ilkin olaraq tətbiq edir. Nəticə etibarilə SameSite mexanizmi, çərəzlərin yalnız güvənli və müəyyən hallarda istifadə edilməsinə icazə verərək saytlar arası hücumları əngəlləyir.
Referer-based validation: Bəzi tətbiqlər, CSRF hücumlarına qarşı müdafiə olunmağa çalışmaq üçün HTTP Referer header-ini istifadə edir və normal olaraq doğrulayır ki, sorğu, tətbiqin öz domenindən gəlib. Bu, adətən CSTF tokeni doğrulamasından daha az effektivdir.
SameSite rejimləri:
Strict: Çərəzlər yalnız eyni sayt üzərindən gələn sorğularda istifadə olunur. Başqa saytlardan gələn sorğular rədd edilir.
Lax: Daha flexible bir rejimdir. Ancaq (form göndərmə və ya vacib data dəyişikliyi kimi) həssas əməliyyatlar üçün çərəzlərin istifadə edilməsini əngəlləyir.
None: Çərəzlərin bütün saytlarda istifadə edilməsinə icazə verir. Ancaq, HTTPS kimi güvənli bağlantı tələb edir.
CSRF tokeni nədir?
CSRF tokeni, server-side tətbiq tərəfindən yaradılan və client ilə paylaşılan, unikal, secret və təxmin edilə bilməyən bir dəyərdir. Form göndərmək kimi həssas bir əməliyyatı icra etmə sorğusunu göndərərkən, client, doğru CSRF tokeni daxil etməlidir. Əks halda, server tələb olunan əməliyyata rədd cavabı verəcək.
CSRF tokenlərini client ilə paylaşmağın geniş yayılmış yolu, bunları HTML formuna gizli bir parametr olaraq daxil etməkdir, məsələn:
Bu formu göndərdikdən sonra aşağıdakı kimi sorğu yaranacaq:
Düzgün tətbiq olunduqda, CSRF tokenləri, bir hakerin qurbanın adından yararlı bir sorğu yaratmasını çətinləşdirəcək və CSRF hücumlarına qarşı müdafiə təmin edəcək. Hakerin CSRF tokeni üçün doğru dəyəri təxmin etmə yolu olmadığı üçün, bunu zərərli sorğuya daxil edə bilməyəcək.
CSRF tokenlərinin bir POST sorğusunda gizli parametrlər kimi göndərilməsinə ehtiyac yoxdur. Məsələn, bəzi tətbiqlər CSRF tokenlərini HTTP header-lərində yerləşdirir. Tokenlərin necə ötürüldüyü, ümumi güvənlik mexanizmlərinin fəaliyyəti üzərində böyük bir təsirə malikdir. Yanlış bir metod istifadəsi nəticəsində hakerlər, bu güvənlik tədbirlərini aşa bilər. Buna görə də, tokenlərin düzgün ötürülməsini təmin etmək vacibdir.
CSRF token doğrulamasında geniş yayılmış qüsurlar
CSRF boşluqları, adətən CSRF tokenlərinin qüsurlu doğrulanmasına görə baş verir. Bu bölmədə, hakerlərin bu müdafiə üsullarını bypass etməsinə imkan verən ən geniş yayılmış problemlərdən bəzilərinə baxacağıq.
Sorğu metodu
CSRF tokeninin doğrulanması, sorğu metodundan asılıdır. Bəzi tətbiqlər, sorğu POST metodunu istifadə etdikdə tokeni düzgün doğrulayır, ancaq GET metodu istifadə edildikdə doğrulamanı ötürür. Bu halda, haker, doğrulamanı bypass etmək üçün GET metoduna keçə və CSRF hücumunu həyata keçirə bilər:
Tokenin mövcudluğu
CSRF tokeninin doğrulanması, tokenin mövcudluğundan asılıdır. Bəzi tətbiqlər, token mövcud olduqda düzgün doğrulayır, ancaq token buraxıldıqda doğrulamanı ötürür. Bu halda, haker, doğrulamanı bypass etmək və bir CSRF hücumunu həyata keçirmək üçün tokeni ehtiva edən bütün parametrləri (yalnız dəyəri deyil) silə bilər:
User session-a bağlı olmaması
Bəzi tətbiqlər, tokeni, sorğunu göndərən istifadəçiyə ilə eyni seansa aid olduğunu doğrulamır. Bunun əvəzinə, tətbiq, qlobal bir "token pool" ilə davam edir və bu pool-da görünən istənilən tokeni qəbul edir. Bu halda, haker, öz hesabını istifadə edərək tətbiqə giriş edib yararlı bir token alır və bu tokeni CSRF hücumunda qurbana göndərir.
Non-session cookie-ə bağlı olması
Əvvəlki boşluğun bir variasiyasında, bəzi tətbiqlər, CSRF tokenini bir çərəzə bağlayır, ancaq seansları izləmək üçün istifadə olunan çərəzə bağlamır. Bu hal, bir tətbiq, (biri seans idarə edən, digəri isə CSRF qoruması üçün olan) 2 fərqli çərçivə istifadə etdikdə baş verir.
Bu halda exploit etmək çox çətindir, ancaq mümkünsüz deyil. Əgər veb saytda, haker tərəfindən istifadəçinin brauzerinə çərəz yerləşdirməsinə icazə verən hər hansısa bir davranış mövcuddursa, onda bu hücum mümkün olacaq. Hücum vektoru olaraq haker, öz hesabını istifadə edərək tətbiqə giriş edib yararlı bir token və əlaqələndirilmiş çərəzi əldə edəcək, cookie-setting davranışından faydalanaraq öz çərəzini qurbanın brauzerinə yerləşdirəcək və öz tokenini CSRF hücumunda qurbana göndərə biləcək.
CSRF hücumu üçün lazım olan cookie-setting davranışının eyni veb tətbiqdə olmasına ehtiyac yoxdur. Eyni DNS domenində olan başqa bir tətbiq də, hədəf tətbiqdə cookie-setting üçün istifadə oluna bilər. Məsələn, staging.demo.normal-website.com ünvanındakı bir tətbiq çərəz yarada bilər. Bu çərəz, secure.normal-website.com ünvanına göndərilə və ordakı proseslərə təsir göstərə bilər. Daha sadə dildə desək, bir subdomen tərəfindən təyin edilən çərəzin scope-u (fəaliyyət sahəsi) uyğun şəkildə tərtib olunubsa, eyni second-level domen daxilindəki başqa subdomenlərə təsir göstərə bilər. Yəni, bütün subdomenlər bir-birindən tam müstəqil deyil və çərəzin düzgün tərtib olunmaması, boşluqlara yol aça bilər.
CSRF token bir çərəzdə asanlıqla çoxaldılır
Bəzi tətbiqlər, istifadəçilərə verdikləri CSRF tokenlərini serverdə saxlamaq əvəzinə, tokenin eynisini həm çərəzdə, həm sorğu parametrində (məsələn, bir form xanasında) saxlayır. Daha sonra bir sorğu gəldikdə, tətbiq yalnız sorğu parametrindəki tokenin, çərəzdəki tokenlə eyni olub-olmadığını yoxlayır. Bu üsula CSRF-ə qarşı "double submit defense" deyilir. Tətbiq olunması asandır və server tərəfindən hər hansısa data saxlama ehtiyacını aradan qaldırır.
Bu üsul tövsiyə olunur. Çünki, bəzi CSRF müdafiə üsullarında, hər istifadəçi üçün serverdə bir token qeydi saxlanılır. Məsələn, bir istifadəçiyə verilən token, serverdə saxlanılır və hər sorğuda bu token yoxlanılır. Ancaq bu, serverin databazada əlavə bir qeyd saxlamısını tələb edir və əlavə bir yük yaradır. Ancaq "double submit defense" üsulunda, belə bir qeydi saxlamağa ehtiyac yoxdur. Token, yalnız istifadəçinin cihazındakı çərəzdə və sorğu ilə göndərilən parametrdə saxlanılır. Server, bunların bir-birilə uyuşub-uyuşmadığını yoxlayır.
Bu halda, veb sayt, hər hansısa cookie setting funksionallığı ehtiva edirsə, attacker, yenə də bir CSRF hücumu həyata keçirə bilər. Burada, attacker-in yararlı bir token əldə etməsinə ehtiyac qalmır. Bunun əvəzinə, özü saxta bir token yaradır (bəlkə doğru formatda, əgər format yoxlanılırsa), çərəz ayarlama funksionallığını istifadə edərək bu saxta tokeni qurbanın brauzerinə yerləşdirir və CSRF hücumunda bu tokeni istifadə edir. Yəni, çərəz ayarlaya bilən bir özəllik varsa, attacker-in aktual tokeni tapmağına ehtiyac qalmır.
SameSite cookie məhdudiyyətlərini bypass etmə
SameSite, bir veb saytın çərəzlərinin digər veb saytlardan gələn sorğulara nə vaxt daxil ediləcəyini müəyyən edən bir brauzer təhlükəsizlik mexanizmidir. SameSite çərəz məhdudiyyətləri, CSRF, cross-site leaks (saytlar arası sızıntılar) və bəzi CORS exploit-ləri daxil olmaqla müxtəlif cross-site hücumlarına qarşı qismən qoruma təmin edir.
2021-ci ildən etibarən, əgər çərəzi təqdim edən veb sayt, öz məhdudiyyət səviyyəsini açıq şəkildə ayarlamasa, Chrome, ilkin olaraq Lax SameSite məhdudiyyətlərini tətbiq edir. Nəticə etibarilə, cross-site hücum vektorlarını hərtərəfli test edə bilmək üçün bu məhdudiyyətlərin necə işlədiyini və potensial olaraq becə bypass edilə biləcəyinini yaxşı anlamaq vacibdir.
Bu bölmədə, ilkin olaraq SameSite mexanizminin necə işlədiyini öyrənəcəyik. Daha sonra, bu məhdudiyyətləri bypass edə biləcəyiniz və başlanğıcda güvənli görünən veb saytlarda CSRF və digər cross-site hücumlarına şərait yaradan ən geniş yayılmış yollardan bəzilərinə baxacağıq.
SameSite çərəzləri konteksində sayt nədir?
SameSite çərəz məhdudiyyətləri kontekstində bir sayt, .com və ya .net kimi top-level domen (TLD), üstəgəl domen adının bir əlavə səviyyəsi ilə müəyyən edilir. Adətən, TLD+1 olaraq adlandılır. Bir sorğunun same-site olub-olmadığını müəyyən edərkən URL sxemi də nəzərə alınır. Bu o deməkdir ki, http://app.example.com ünvanından https://app.example.com ünvanına gedən bir keçid, əksər brauzerlər tərəfindən cross-site olaraq qiymətləndirilir.
eTLD (Effective top-level domain), əslində praktikada TLD kimi davranın çox parçalı uzantıları ifadə edir. Məsələn, .co.uk normalda bir ölkə kodu kimi görünür, ancaq bu cür uzantılar adətən bir TLD kimi dəyərləndirilir. Çox parçalı uzantı dedikdə, domen adının sonunda bir neçə hissədən ibarət olan uzantılar nəzərdə tutulur. Məsələn, .edu.az Azərbaycanda təhsil qurumları üçün nəzərdə tutulmuş domendir.
Site ilə origin arasındakı fərqlər nədir?
Site ilə origin arasındakı fərq, onların scope-u, yəni əhatə dairəsidir. Site, bir neçə domeni əhatə edir, origin-ə isə yalnız biri daxildir. Nə qədər də, bir-biriləri ilə yaxından əlaqəli olsalar da, bu terminləri biri-birinin əvəzinə istifadə etməmək lazımdır. Eyni sxemi, domen adını və portu paylaşan 2 URL-nin same-origin olduğu qəbul edilir.
Bu nümunədən gördüyünüz kimi, site termini yalnız domen adının sxemini və son hissəsini nəzərə aldığı üçün daha az spesifikdir. Bu o deməkdir ki, cross-origin sorğu, same-site ola bilər, ancaq tərsi olmayacaq.
https://example.com
https://example.com
Bəli
Bəli
https://app.example.com
https://intranet.example.com
Bəli
Xeyr. Uyumlu olmayan domen adı
https://example.com
https://example.com:8080
Bəli
Xeyr. Uyumlu olmayan port
https://example.com
https://example.co.uk
Xeyr. Uyumlu olmayan eTLD
Xeyr. Uyumlu olmayan domen adı
https://example.com
http://example.com
Xeyr. Uyumlu olmayan sxem
Xeyr. Uyumlu olmayan sxem
Bu, mühüm fərqdir. Çünki bir veb saytda ixtiyari (yəni kontrolsuz) JavaScript kodunun çalışmasına icazə verən bir təhlükəsizlik boşluğu varsa, bu boşluqdan faydalanaraq eyni sayta aid digər domenlərdəki mühafizə üsulları bypass edilə bilər. Məsələn, same-origin qaydasına görə bir domen, yalnız öz resursuna aid datalara müraciət edə bilər. Ancaq same-site konteksti, məsələn example.com saytına aid subdomenləri (blog.example.com və s.) eyni sayt kimi qiymətləndirir. Nəticə etibarilə, bir JavaScript boşluğu varsa, attacker, bu boşluğu istifadə edərək eyni sayta bağlı digər domenlərdəki müdafiələri sıradan çıxarda bilər. Yəni tək bir boşluq, bütün sayta yayıla bilər.
SameSite necə işləyir?
SameSite mexanizmi tanıdılmazdan əvvəl, brauzerlər, çərəzləri hər sorğuda, o sorğunu yaradan domenə göndərirdi. Hətta, bu sorğu üçüncü tərəf bir veb sayt tərəfindən tələb olunsa belə. SameSite mexanizmi, brauzerlərin və veb sayt sahiblərinin, çərəzlərin hansı cross-site sorğularında (yəni başqa bir saytdan gələn sorğularda) istifadə ediləcəyini məhdudlaşdırmasına imkan verir. Bu da, xüsusilə CSRF hücumlarına qarşı müdafiə təmin edir. Çünki CSRF hücumları, qurbanın brauzerini, zərərli bir əməliyyatı icra edəcək bir sorğunu göndərməyə məcbur edir. Bu cür sorğularda, adətən qurbanın öz hesabına daxil olması və hesabına bağlı çərəzlərinin mövcud olması lazımdır. Əgər, brauzer bu çərəzləri sorğuya daxil etməsə, hücum uğursuz olur. Hazırda, tanınmış bütün brauzerlər SameSite məhdudiyyət səviyyələri dəstəkləyir:
Strict
Lax
None
Developer-lər, ayarladıqları hər çərəz üçün manual olaraq bir məhdudiyyət səviyyəsi konfiqurasiya edə bilər ki, bu da onlara bu çərəzlərin nə vaxt istifadə ediləcəyi ilə bağlı daha çox nəzarət imkanı verir. Bunu etmək üçün Set-Cookie response header-inə SameSite atributunu və tərcih etdiyi dəyəri daxil etmək yetərlidir.
Bu, CSRF hücumlarına qarşı bir az müdafiə təmin edir, ancaq bu məhdudiyyətlərin heç biri müdafiəyə tam zəmanət vermir.
Last updated