Bloq

Tarix: 03.10.2026

Saat: 01:04

CSRF və XSS: veb tətbiqlərin iki klassik zəifliyinə dair tam bələdçi

Giriş

Hər gün onlarla xidmətə daxil oluruq: poçt, bank, sosial şəbəkələr, tədris platformaları, onlayn mağazalar. Bütün bunlar etibar üzərində qurulub. Sayt brauzerə güvənir və ondan sessiya identifikatoru olan cookie-ləri qəbul edir. Brauzer də sayta güvənir və saytın göndərdiyi JavaScript kodunu icra edir. İstifadəçi isə hər ikisinə güvənir.

XSS və CSRF hücumları məhz bu etibardan sui-istifadə edir. Hər ikisi illərdir ən geniş yayılmış veb zəifliklər sırasındadır və OWASP Top 10 reytinqində müntəzəm olaraq yer alır (XSS indi Injection kateqoriyasına aiddir, CSRF isə Broken Access Control ilə əlaqəlidir). Yaşlarına baxmayaraq, bu səhvləri həm yeni başlayanlar, həm də təcrübəli komandalar buraxır.

Bu yazıda aşağıdakıları öyrənəcəksiniz:

hər iki hücumun necə işlədiyi və aralarındakı əsas fərqlər;
hansı növləri və ssenariləri var;
kod, başlıqlar və arxitektura səviyyəsində necə qorunmaq olar;
tətbiqinizi necə yoxlamaq olar və ən çox rast gəlinən səhvlər hansılardır.

Hissə 1. Əsaslar: brauzer niyə həssasdır?

Hər iki hücumu anlamaq üçün brauzerin üç əsas mexanizmini bilmək lazımdır.

1. Cookie-lər avtomatik göndərilir. bank.example saytına daxil olmusunuzsa, brauzer həmin domenə göndərilən hər sorğuya cookie-lərinizi əlavə edəcək, sorğunun hansı səhifədən başladılmasından asılı olmayaraq. CSRF-in əsasında bu fakt dayanır.

2. Same-Origin Policy (SOP). Bir mənbədən (sxem + domen + port) gələn skript başqa mənbənin məlumatını sərbəst oxuya bilməz. Lakin SOP sorğuların oxunmasını məhdudlaşdırır, göndərilməsini yox. Buna görə kənar səhifə bankınıza sorğu göndərə bilər (CSRF), amma cavabı oxuya bilməz.

3. Brauzer səhifədəki istənilən JavaScript-i icra edir. O, «developerin yazdığı skript» ilə «hücumçunun şərh sahəsi vasitəsilə yerləşdirdiyi skript» arasında fərq qoymur. Kod səhifənin HTML-inə düşübsə, həmin saytın səlahiyyətləri ilə icra olunacaq. XSS-in əsası budur.

Hissə 2. XSS (Cross-Site Scripting)

Bu nədir?

XSS tətbiq istifadəçidən alınan məlumatı lazımi emal etmədən səhifəyə daxil etdikdə və brauzer onu kod kimi şərh etdikdə yaranır. Hücumçu etibarlı saytın kontekstində, yəni saytın özünün hüquqları ilə öz JavaScript kodunu icra etmək imkanı qazanır.

Sadə tədris nümunəsi: saytda axtarış sorğu sətrini səhifədə göstərir: «Sorğu üzrə nəticələr: …». Sorğu HTML-ə olduğu kimi yerləşdirilirsə, adi söz əvəzinə <script> teqi daxil etmək olar və brauzer onun içindəki kodu icra edəcək.

XSS növləri

Stored XSS (saxlanılan). Zərərli məlumat serverdə saxlanılır: şərhdə, profil adında, rəydə, çat mesajında. Səhifəni açan hər kəs avtomatik olaraq zərərli kodu alır. Qurbandan səhifəyə daxil olmaqdan başqa heç nə tələb olunmadığı üçün bu, ən təhlükəli növdür.

Reflected XSS (əks olunan). Məlumat sorğuda (adətən URL parametrində) gəlir və cavabda dərhal «əks olunur». Hücumun işləməsi üçün qurbanı xüsusi hazırlanmış linkə keçməyə inandırmaq lazımdır: e-poçt, mesencer və ya qısaldılmış link vasitəsilə.

DOM-based XSS. Zəiflik tamamilə client tərəfdəki JavaScript-də olur. Server qüsursuz ola bilər, amma səhifə skripti location.hash, location.search və ya document.referrer-dən məlumat götürüb DOM-a təhlükəli şəkildə (innerHTML, document.write, eval vasitəsilə) yazır.

Blind XSS. Saxlanılan XSS-in elə bir növü ki, zərərli kod hücumçuda yox, sistemin qapalı hissəsində, məsələn, əməkdaşın istifadəçi müraciətlərinə baxdığı admin panelində işə düşür. Administratorların yüksək səlahiyyətlərinə görə nəticələr xüsusilə ciddi ola bilər.

XSS niyə təhlükəlidir?

Sayt kontekstində kod icra edən hücumçu aşağıdakıları edə bilər:

sessiya cookie-lərini oğurlamaq (HttpOnly bayrağı yoxdursa) və qurban adı altında daxil olmaq;
səhifə məlumatlarını oxumaq: şəxsi mesajlar, hesab nömrələri, formaların məzmunu;
istifadəçi adından əməliyyatlar icra etmək: mesaj göndərmək, ayarları dəyişmək, köçürmə etmək;
səhifənin məzmununu dəyişmək, məsələn, real saytda saxta giriş formasını göstərmək;
klaviatura girişini ələ keçirmək;
özünü yaymaq, yəni öz-özünə yayılan «qurdlar» yaratmaq.

Klassik tarixi nümunə: 2005-ci ildə MySpace-də Samy qurdu bir neçə saat ərzində müəllifini bir milyondan çox istifadəçinin dostlarına əlavə etdi. Qurd profillərdəki saxlanılan XSS-dən istifadə edirdi. Bu hadisə dərsliklərə düşdü və belə zəifliyin nə qədər sürətlə yayıla biləcəyini aydın göstərdi.

XSS-dən necə qorunmaq olar?

Əsas prinsip: kənardan gələn istənilən məlumat əksi sübut olunana qədər etibarsız hesab olunur və səhifəyə yerləşdirilməzdən əvvəl kontekstə uyğun emal edilməlidir.

1. Çıxışın kontekstə uyğun escape edilməsi (output encoding). Bu, əsas tədbirdir. Eyni simvol səhifənin müxtəlif yerlərində müxtəlif cür təhlükəlidir, ona görə escape üsulu kontekstdən asılıdır:

Çıxış kontekstiNə etmək lazımdırHTML gövdəsi<, >, &, dırnaqları HTML entity ilə əvəz etməkAtribut dəyəriDırnaqları escape etmək, dəyəri həmişə dırnaq içinə almaqJavaScriptMəlumatı koda birbaşa yerləşdirməmək; JSON və ya data-atributlar vasitəsilə ötürməkURLURL-kodlaşdırmanı tətbiq etmək və sxemi yoxlamaq (javascript: qadağan edilməlidir)CSSEtibarsız məlumatı üslublara yerləşdirməmək

2. Avtomatik escape edən şablon mühərriklərindən və framework-lərdən istifadə edin. Müasir alətlər (React, Vue, Angular, Django Templates, Jinja2, Twig, Razor) çıxışı default olaraq escape edir. Təhlükə developer müdafiəni qəsdən keçdikdə yaranır: React-də dangerouslySetInnerHTML, Vue-də v-html, Django və Jinja2-də |safe filtri, Angular-da bypassSecurityTrust.... Belə yerlərin hər biri code review zamanı xüsusi nəzarətdə olmalıdır.

3. DOM ilə işləmək üçün təhlükəsiz metodlar.

javascript

// Təhlükəli: məlumat HTML kimi şərh olunur

element.innerHTML = userInput;

// Təhlükəsiz: məlumat mətn sayılır

element.textContent = userInput;

eval(), new Function(), setTimeout("sətir"), document.write() istifadə etməkdən çəkinin.

4. HTML həqiqətən lazım olduqda sanitizasiya. İstifadəçilərə formatlaşdırma icazəsi verilibsə (məqalə redaktoru, markup ilə şərhlər), DOMPurify kimi yoxlanılmış kitabxanadan istifadə edin. Müntəzəm ifadələrə əsaslanan öz «filtrlərinizi» yazmayın: onları demək olar ki, həmişə keçmək mümkündür.

5. Content Security Policy (CSP). Bu, brauzerə skriptlərin hansı mənbələrdən yüklənib icra edilə biləcəyini bildirən başlıqdır. Səhifəyə zərərli kod düşsə belə, sərt siyasət onun icrasının qarşısını ala bilər.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-TESADUFI_QIYMET'; object-src 'none'; base-uri 'none'

CSP üzrə tövsiyələr:

script-src-də 'unsafe-inline' və 'unsafe-eval'-dan çəkinin;
zəruri inline skriptlər üçün nonce və ya hash istifadə edin;
əvvəlcə Content-Security-Policy-Report-Only rejimini aktivləşdirin ki, pozuntuları görəsiniz və saytı sındırmayasınız;
yadda saxlayın ki, CSP əlavə təbəqədir, escape-i əvəz etmir.

6. Cookie bayraqları. HttpOnly JavaScript-in cookie-ni oxumasını qadağan edir, buna görə XSS olsa belə document.cookie vasitəsilə sessiya identifikatorunu oğurlamaq mümkün olmur. Secure bayrağı cookie-nin yalnız HTTPS ilə ötürülməsini təmin edir. Nəzərə alın ki, XSS zamanı hücumçu yenə də qurbanın brauzerindən birbaşa onun adından sorğu göndərə bilər, yəni HttpOnly zərəri azaldır, problemi aradan qaldırmır.

7. Trusted Types. Brauzerlərin (Chromium) müasir mexanizmi: innerHTML kimi «təhlükəli» yerlərə yazmazdan əvvəl kodu xüsusi siyasətlərdən keçirməyə məcbur edir. Böyük kod bazalarında DOM-based XSS-dən qorunmaq üçün yaxşı uyğun gəlir.

8. Daxil olan məlumatların validasiyası. Tipi, uzunluğu, formatı yoxlayın. Amma yadda saxlayın: validasiya hücum səthini azaldır, XSS-dən isə məhz çıxışda escape qoruyur.

Hissə 3. CSRF (Cross-Site Request Forgery)

Bu nədir?

CSRF (saytlararası sorğunun saxtalaşdırılması) autentifikasiya olunmuş istifadəçinin brauzerini, o artıq daxil olduğu saytda istənilməyən sorğu göndərməyə məcbur edir. Server düzgün cookie-ləri görür və sorğunu istifadəçinin özünün göndərdiyini düşünür.

Mühüm xüsusiyyət: hücumçu sorğunun cavabını görmür və məlumatı birbaşa oğurlamır. O, qurbanı əməliyyat icra etməyə məcbur edir: e-poçtu dəyişmək, parolu dəyişmək, köçürmə etmək, hesabı silmək, ayarları dəyişmək.

Bənzətmə. Bank tapşırığını imzalayıb qələmi stolun üstündə qoymusunuz. Kimsə sizə başqa bir tapşırıq verib. İmza həqiqidir, amma siz məhz bu sənədi imzalamaq niyyətində deyildiniz. Server yalnız «imzanı» (cookie) yoxlayır, əməliyyatı istəyib-istəmədiyinizi soruşmur.

Uğurlu CSRF hücumu üçün şərtlər

Adətən üç şey lazımdır:

Sorğu ilə icra oluna bilən əhəmiyyətli əməliyyat var (e-poçtun dəyişdirilməsi, köçürmə, ayarların dəyişməsi).
Autentifikasiya cookie əsasındadır (və ya brauzerin avtomatik əlavə etdiyi başqa mexanizm, məsələn, Basic Auth).
Sorğu proqnozlaşdırıla biləndir: hücumçu bütün parametrləri bilir və gizli dəyərləri təxmin etməli deyil.

Nümunə ssenari

İstifadəçi shop.example saytının şəxsi kabinetinə daxil olur. Sessiya cookie-ləri brauzerdə saxlanılır.
Qonşu tabda çatda və ya e-poçtda aldığı linkdəki səhifəni açır.
Səhifədə shop.example/account/change-email ünvanını hədəfləyən, avtomatik göndərilən gizli forma və ya sorğu var.
Brauzer cookie-ləri əlavə edir, server «avtorizasiya olunmuş» sorğunu görür və e-poçtu hücumçunun ünvanı ilə əvəz edir.
Hücumçu yeni ünvana parolun bərpasını sorğulayır və hesab ələ keçirilir.

Bu cür real nümunələr: ev routerlərinə kütləvi hücumlar (veb interfeysdə CSRF vasitəsilə DNS ayarlarının dəyişdirilməsi), eləcə də sosial şəbəkələrdə və internet bankinqlərdə bir gizli əməliyyatın hesab ayarlarını dəyişdiyi zəifliklər.

GET sorğuları niyə xüsusilə təhlükəlidir?

Tətbiq vəziyyəti dəyişən əməliyyatı GET sorğusu ilə icra edirsə (məsələn, /delete?id=5), hücum üçün səhifədəki adi şəkil və ya link belə kifayətdir. Ona görə vəziyyətin dəyişdirilməsi yalnız POST, PUT, PATCH və ya DELETE metodları ilə aparılmalıdır, GET isə təhlükəsiz qalmalı və məlumatı dəyişməməlidir.

CSRF-dən necə qorunmaq olar?

1. CSRF tokenləri (synchronizer token pattern). Server istifadəçi sessiyasına bağlı təsadüfi, təxmin edilməz token yaradır, onu formalara yerləşdirir və vəziyyəti dəyişən hər sorğuda yoxlayır. Hücumçu bu tokeni bilmir və Same-Origin Policy səbəbindən onu oxuya bilmir, buna görə sorğunu saxtalaşdıra bilməz.

html

<button>Yadda saxla</button>

</form>

Tokenlər üçün qaydalar: kifayət qədər uzunluq və kriptoqrafik təsadüfilik; sessiyaya bağlılıq; bütün vəziyyəti dəyişən sorğular üçün serverdə yoxlama; tokenin URL-də ötürülməməsi.

2. Double Submit Cookie. Server tərəfində sessiya saxlanmayan tətbiqlər üçün alternativdir: token həm cookie-də, həm də sorğunun gövdəsində və ya başlığında ötürülür, server onları müqayisə edir. Etibarlılıq üçün tokeni imzalamaq və ya sessiyaya bağlamaq məsləhətdir.

3. Cookie üçün SameSite atributu. Bu atribut brauzerə saytlararası sorğular zamanı cookie-nin nə vaxt göndəriləcəyini bildirir.

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax

Strict: cookie heç bir saytlararası sorğuda göndərilmir (maksimum qoruma, amma xarici linklərlə keçidlərdə istifadəçiləri narahat edə bilər);
Lax: cookie yalnız təhlükəsiz «yuxarı səviyyəli» keçidlərdə (link üzrə GET) göndərilir, saytlararası POST və yerləşdirilmiş elementlərdən gələn sorğularda göndərilmir. Əksər müasir brauzerlər Lax-ı default tətbiq edir;
None: cookie həmişə göndərilir (Secure tələb olunur).

SameSite əla əlavə təbəqədir, lakin tokenlərin tam əvəzedicisi deyil: davranış brauzerdən asılıdır, bəzi ssenarilər (məsələn, subdomenlər, vəziyyəti dəyişən GET sorğuları ilə yan keçmə) riskli qalır.

4. Origin və Referer başlıqlarının yoxlanılması. Vəziyyəti dəyişən sorğular üçün server Origin (və ya Referer) başlığının gözlənilən domenə uyğun olduğunu yoxlaya bilər. Müasir brauzerlər POST sorğuları ilə Origin başlığı göndərir və bu, yaxşı əlavə filtrdir. Sec-Fetch-Site başlığı da saytlararası sorğuları adi sorğulardan ayırmağa kömək edir.

5. API üçün xüsusi başlıqlar. AJAX və API üçün öz başlığınızı (məsələn, X-Requested-With və ya Authorization-da token) tələb etmək olar. Belə başlıqların adi forma ilə saytlararası göndərilməsi mümkün deyil, JavaScript üçün isə CORS icazəsi tələb olunacaq. Authorization (Bearer) başlığındakı tokenlər brauzer tərəfindən avtomatik əlavə olunmur, ona görə belə API-lər təbiətcə klassik CSRF-ə davamlıdır (amma XSS zamanı tokenin oğurlanmasına həssasdır).

6. Kritik əməliyyatlar üçün təkrar autentifikasiya. Parolun, e-poçtun dəyişdirilməsi, ödəniş, hesabın silinməsi: parol, SMS kodu və ya autentifikator tətbiq vasitəsilə təsdiq tələb edin.

7. CORS-a CSRF-dən qoruma kimi güvənməyin. CORS cavabın oxunmasını məhdudlaşdırır, lakin «sadə» sorğular (məsələn, forma POST-u) CORS-dan asılı olmayaraq serverə çatır və icra olunur.

8. Framework-lərin daxili müdafiəsindən istifadə edin. Django (CsrfViewMiddleware), Laravel (@csrf), Spring Security, ASP.NET Core (antiforgery), Rails (protect_from_forgery) müdafiəni default olaraq aktivləşdirir. Əsas məsələ onu «işləsin deyə» söndürməmək və AJAX sorğularına token əlavə etməyi unutmamaqdır.

Hissə 4. XSS və CSRF: müqayisə

XSSCSRFMahiyyətEtibarlı saytda kənar kodun icrasıİstifadəçi adından istənilməyən sorğunun göndərilməsiNədən istifadə edirİstifadəçinin (brauzerin) sayta etibarındanSaytın istifadəçi brauzerinə etibarındanKod harada icra olunurQurbanın brauzerində, həssas saytın domenindəHücumçunun kodu kənar saytda icra olunur; sorğu hədəf sayta gedirMəlumatı oxuya bilirmiBəli, səhifə kontekstindəXeyr, yalnız əməliyyatları çağıra bilirAutentifikasiya lazımdırmıMütləq deyilBəli, qurban avtorizasiya olunmalıdırƏsas müdafiəÇıxışın escape edilməsi, CSPCSRF tokenləri, SameSiteƏlavə müdafiəHttpOnly, Trusted Types, sanitizasiyaOrigin yoxlanışı, təkrar təsdiq

İkisi arasındakı əsas əlaqə: XSS CSRF müdafiəsini dəyərsizləşdirir. Hücumçu saytınızda skript icra edə bilirsə, CSRF tokenini birbaşa səhifədən oxuyub düzgün sorğu göndərə bilər. Ona görə XSS-in aradan qaldırılması CSRF-dən etibarlı qorunmanın məcburi şərtidir.

Hissə 5. Tətbiqinizi necə yoxlamaq olar?

XSS üçün:

istifadəçi məlumatının səhifəyə düşdüyü bütün yerləri tapın: axtarış sahələri, şərhlər, profillər, URL parametrləri, başlıqlar, yüklənən faylların adları;
xüsusi simvolların (< > " ' &) markup kimi yox, mətn kimi göstərildiyini yoxlayın;
DOM ssenarilərini yoxlayın: location.hash və location.search-dən gələn məlumat;
innerHTML, eval, dangerouslySetInnerHTML axtaran statik kod analizindən (SAST) və linterlərdən istifadə edin;
OWASP ZAP və ya Burp Suite kimi skaner və proksilərdən istifadə edin (yalnız öz sistemlərinizdə və ya yazılı icazə ilə).

CSRF üçün:

vəziyyəti dəyişən bütün sorğuları siyahıya alın və hər biri üçün token və ya başqa müdafiənin olduğunu yoxlayın;
tokensiz və ya yad tokenlə sorğunun rədd edildiyini yoxlayın;
GET ilə dəyişdirici əməliyyatların olmadığını yoxlayın;
cookie-lərdə SameSite təyin olunduğuna əmin olun;
tokenin istifadəçilər arasında təkrar istifadə olunmadığını və URL-də ötürülmədiyini yoxlayın.

Harada təhlükəsiz məşq etmək olar: OWASP Juice Shop, DVWA (Damn Vulnerable Web Application), PortSwigger Web Security Academy laboratoriyaları, WebGoat. Bunlar təlim üçün xüsusi olaraq yaradılmış zəif mühitlərdir. Yad sistemləri yalnız sahibinin açıq icazəsi olduqda test edin.

Hissə 6. Developerlərin tez-tez buraxdığı səhvlər

«Filtrimiz var, deməli qorunuruq». Qara siyahılar («script sözünü siləcəyik») onlarla üsulla keçilir. Müdafiə escape və ağ siyahılar üzərində qurulur.
Çıxışda yox, girişdə escape. Məlumat bazaya yazılarkən yox, çıxış anında və kontekstə uyğun escape edilməlidir.
Söndürülmüş framework müdafiəsi. CSRF yoxlaması debug zamanı «müvəqqəti» söndürülür və geri qoşmaq unudulur.
Token var, amma yoxlanılmır. Token yaradılır və formaya əlavə olunur, serverdə isə yoxlama yoxdur və ya bütün metodlar üçün aparılmır.
GET ilə məlumatın dəyişdirilməsi.
«Daxili» mənbələrə etibar. Bazadan, kənar API-lərdən gələn məlumat, fayl adları, HTTP başlıqları da zərərli kod daşıya bilər.
Çox yumşaq CSP (unsafe-inline, mənbələrdə *): formal olaraq var, amma heç nəyi qorumur.
Tokenlərin nəticələrini anlamadan localStorage-da saxlanması: istənilən XSS zamanı onlar oğurlanacaq.

Hissə 7. Developer üçün çek-list

XSS

Bütün çıxış kontekstə uyğun escape edilir
Avtomatik escape edən şablon mühərriki istifadə olunur
Kodda etibarsız məlumatla innerHTML, eval, document.write yoxdur
İstifadəçi HTML-i DOMPurify və ya analoqundan keçir
Sərt CSP qurulub (unsafe-inline olmadan)
Sessiya cookie-lərində HttpOnly və Secure var
dangerouslySetInnerHTML, v-html, |safe olan bütün yerlər audit edilib

CSRF

Vəziyyəti dəyişən bütün sorğular token ilə qorunur
Cookie-lərdə SameSite atributu var (Lax və ya Strict)
Vəziyyətin dəyişməsi yalnız POST/PUT/PATCH/DELETE ilə
Origin / Sec-Fetch-Site yoxlanılır
Kritik əməliyyatlar təkrar təsdiq tələb edir
Framework-in daxili müdafiəsi söndürülməyib

Tez-tez verilən suallar

React istifadə edirəmsə, XSS barədə narahat olmalıyammı?

Bəli, baxmayaraq ki, risk daha aşağıdır. React çıxışı default olaraq escape edir, lakin XSS dangerouslySetInnerHTML, href-də təhlükəli URL-lər (məsələn, javascript:), üçüncü tərəf kitabxanalar və səhv server tərəfi renderi vasitəsilə mümkündür.

Authorization başlığında JWT olan API-m varsa, CSRF müdafiəsi lazımdırmı?

Token yalnız başlıqda ötürülürsə və cookie-də saxlanmırsa, klassik CSRF işləmir. Amma JWT cookie-dədirsə, müdafiə lazımdır. Tokenin localStorage-da saxlanması isə onu XSS zamanı həssas edir.

SameSite=Lax kifayətdirmi?

Bir çox tətbiq üçün bu yaxşı baza müdafiəsidir, lakin kritik əməliyyatlar üçün tokenlərdən və əlavə yoxlamalardan (defense in depth) istifadə etmək lazımdır.

Hansı daha vacibdir: XSS-dən, yoxsa CSRF-dən qorunmaq?

Birini seçmək olmaz: XSS CSRF müdafiəsini keçir, ona görə onun aradan qaldırılması prioritetdir, amma CSRF müdafiəsi də məcburidir.

Nəticə

XSS və CSRF ekzotika deyil, veb inkişafın əsas gigiyenasıdır. Hər iki zəiflik onilliklərdir məlumdur, yaxşı öyrənilib və nisbətən sadə qaydalarla qarşısı alınır:

kənardan gələn məlumata etibar etməyin və çıxışı kontekstə uyğun escape edin;
təhlükəsiz API-lərdən istifadə edin (innerHTML əvəzinə textContent, yoxlanılmış sanitizerlər);
vəziyyəti dəyişən sorğuları tokenlər və SameSite cookie ilə qoruyun;
müdafiə təbəqələri əlavə edin: CSP, HttpOnly, Secure, Origin yoxlaması;
framework-lərin daxili mexanizmlərini söndürməyin;
tətbiqinizi müntəzəm test edin və xüsusi təlim stendlərində öyrənin.

Təhlükəsizlik tək bir «sehrli ayar» deyil, təbəqələr toplusudur və hər biri risklərin öz hissəsini bağlayır. Yuxarıdakı çek-listdən başlayın, tipik problemlərin çoxunu artıq aradan qaldırmış olacaqsınız.

Mənbələr və faydalı keçidlər

Nəzəriyyə və hücumların təsviri

OWASP: Cross Site Scripting (XSS): https://owasp.org/www-community/attacks/xss/
OWASP: Cross Site Request Forgery (CSRF): https://owasp.org/www-community/attacks/csrf
OWASP Top 10: https://owasp.org/Top10/
PortSwigger Web Security Academy: XSS: https://portswigger.net/web-security/cross-site-scripting
PortSwigger Web Security Academy: CSRF: https://portswigger.net/web-security/csrf

Müdafiə bələdçiləri

OWASP Cheat Sheet: XSS Prevention: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
OWASP Cheat Sheet: CSRF Prevention: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
MDN: Content Security Policy (CSP): https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
MDN: HTTP cookies (HttpOnly, Secure, SameSite): https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
MDN: Same-origin policy: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
web.dev: SameSite cookies explained: https://web.dev/articles/samesite-cookies-explained
DOMPurify (HTML sanitizasiya kitabxanası): https://github.com/cure53/DOMPurify

Təlim mühitləri (təhlükəsiz məşq üçün)

OWASP Juice Shop: https://owasp.org/www-project-juice-shop/
OWASP WebGoat: https://owasp.org/www-project-webgoat/
PortSwigger Web Security Academy: https://portswigger.net/web-security

Tarixi nümunə

Samy (MySpace qurdu, 2005): https://en.wikipedia.org/wiki/Samy_(computer_worm)

İndi haradan başlamaq

Əgər yolun hələ əvvəlindəsinizsə və hansı fundamentdən başlamağı hələ qərara almamısınızsa — şəbəkələr, əməliyyat sistemləri, Linux-un əsasları və hücumlar haqqında baza anlayış, ilk praktiki pentest kursunuzu açmazdan əvvəl formalaşmalıdır.

Məhz belə bir fundament qurmaq istəyirsinizsə — JetSchool-da kibertəhlükəsizlik kursundan başlayın.

Teqlər:

Kibertəhlükəsizlik XSS CSRF