Kurs yakuni: har zaiflik bitta buzilgan ishonch chegarasi

Web xavfsizlik amaliyoti kursining oxiriga keldik. To'qqizta zaiflikni nazariyadan emas, o'z qo'limiz bilan ishga tushirdik: IDOR, XSS, CSRF, SSRF, SQLi, autentifikatsiya, path traversal, command injection va business logic. Har biri boshqacha ko'rindi, boshqa payload talab qildi, boshqa joyga tegdi.

Bu dars yangi zaiflik o'rgatmaydi. U ular orasidagi bog'lanishni ko'rsatadi — chunki to'qqizta zaiflik aslida bitta g'oyaning to'qqizta niqobi. O'sha g'oyani bir marta tushunsangiz, keyingi zaiflikni ham, hali kashf qilinmaganini ham taniysiz.

Bu dars kimga: butun kursni tugatgan bo'lsangiz. Har bo'limda oldingi darslarga qaytamiz, shuning uchun ularni yoningizda tuting.

Bitta g'oya, to'qqizta niqob#

Kursning har darsi bitta jumla bilan boshlandi — "buzilgan taxmin". Ularni yonma-yon qo'ying:

Misol

IDOR         "ID'ni taxmin qila olmaydi"
XSS          "kiritilgan matn — matn"
CSRF         "cookie bilan keldi, demak o'zi yubordi"
SSRF         "server faqat men bergan manzilga boradi"
SQLi         "so'rovni satr qo'shib yasayman"
Auth         "parol to'g'ri bo'lsa kiritaman"
Traversal    "fayl nomi — bitta fayl nomi"
Command inj  "bu qiymatni buyruqqa qo'shaman"
Logic        "jarayon men dizayn qilgancha ketadi"

Sakkiztasi bitta gapning takrori: ishonchsiz ma'lumot ishonchli chegaradan tekshiruvsiz o'tadi. Faqat "chegara" har safar boshqa:

XSS'da — brauzerdagi HTML,
SQLi'da — ma'lumotlar bazasidagi so'rov,
command injection'da — shell,
path traversal'da — fayl tizimi,
SSRF'da — serverning tarmoq ulanishi,
IDOR/logic'da — ilovaning ruxsat qarori.

Ma'lumot va kod, ma'lumot va buyruq, ma'lumot va yo'l — hamma joyda o'sha chegara. Zaiflik — o'sha chegara buzilgan joy.

Bitta savol — barcha zaifliklar uchun

Har yangi funksiyani ko'rganda bitta savol bering: "Bu yerda ishonchsiz ma'lumot qaysi ishonchli chegaradan o'tyapti, va u yo'lda tekshirilyaptimi?" Kursning butun mag'zi shu savolda.

Ikki takrorlangan naqsh#

Zaifliklarni bog'lovchi ikki naqshni butun kurs bo'ylab ko'rdik. Ular darslar orasida "ipdek" o'tadi.

1-naqsh: kim ≠ nimaga ruxsat#

IDOR da autentifikatsiya (kim) bilan avtorizatsiya (nimaga ruxsat) chalkashib ketdi. Xuddi shu chalkashlik:

CSRF — cookie "kim"ni aytadi, "niyat"ni emas.
Autentifikatsiya — 2FA tokeni "kim"ni tasdiqlaydi, lekin majburiy emas.
Business logic — email domeni "kim admin"ni hal qildi.

Saboq: "kimligini bilish" hech qachon "nimaga ruxsat berish" degani emas. Ruxsat har obyekt, har amal uchun alohida, serverda tekshirilishi kerak.

2-naqsh: denylist doim teshik#

SQLi, XSS, SSRF, path traversal, command injection — hammasida "xavfli belgini bloklash" (denylist) chetlab o'tildi: kodlash, muqobil yozuv, kontekst almashishi bilan.

Saboq: nimani taqiqlashni sanashga urinsangiz, doim bittasini unutasiz. To'g'ri yechim — ma'lumotni koddan ajratish (parametrlash, qochirish, argument ro'yxati), taqiqlash emas.

Yopishning umumiy qoidalari#

Kurs davomida har dars Django yechimi bilan tugadi. Ularni bir ro'yxatga yig'amiz — bu sizning tekshiruv varag'ingiz:

Shpargalka

Parametrlang SQLiqiymatni so'rovga qo'shma, alohida ber (ORM)

Chiqishda qochir XSS{{ }} shablon, |safe dan qoch

Token + SameSite CSRF{% csrf_token %}, middleware'ni o'chirma

Egalikni cheklab ol IDORget_queryset filter(user=request.user)

Argument ro'yxati Cmd injshell=False, subprocess([...])

Yo'lni yech Traversalrealpath, base ichida ekanini tekshir

URL emas, ID SSRFfoydalanuvchi tanlasin, URL server biladi

Serverda tekshir Logicnarx/rol/chegarani mijozdan olma

Bir xil javob Authusername oqmasin, rate limit qo'y

Va ustidan — chuqurlik uchun ikkinchi qatlam: bu sayt ishlatadigan Content-Security-Policy (XSS uchun), rate limiting (auth/DoS uchun), tarmoq cheklovi (SSRF uchun). Birlamchi himoya har doim ildizda — ajratish, tekshirish — ikkinchi qatlam esa xato bo'lganda ushlab qoladi.

Django himoyasidan chiqmang

Django sizni ko'p narsadan himoya qiladi — agar undan chiqmasangiz. ORM parametrlaydi, shablon qochiradi, CSRF middleware tekshiradi, authenticate() timing'ni tenglaydi. Zaiflik deyarli har doim ORM'dan chiqib xom SQL yozganda, |safe ishlatganda, @csrf_exempt qo'yganda, shell=True chaqirganda paydo bo'ladi. Freymvork bergan yo'ldan chiqishdan oldin ikki marta o'ylang.

Yakuniy loyiha#

Bu kursni tugatganingizni bitta narsa isbotlaydi: o'z zaif ilovangizni yozib, uni o'zingiz yopish. Nazariya emas, ishlaydigan kod.

Vazifa. Kichik Django ilova yozing — masalan "eslatmalar" (har foydalanuvchi o'z eslatmalarini yozadi, ko'radi, o'chiradi). Unga ataylab uchta zaiflik joylang:

Bitta IDOR — eslatmani ID bo'yicha egasini tekshirmasdan bering.
Bitta XSS — eslatma matnini |safe bilan chiqaring.
Bittasini o'zingiz tanlang — SQLi (raw bilan), yoki business logic (bir maydonga mijozdan ishonch).

Keyin — har birini buzing va yoping:

Har zaiflikni Burp bilan ishga tushiring (birinchi darsdagi ko'nikma).
Har birini tuzating — kurs yakunidagi qoidalar bo'yicha.
Har biriga test yozing — hujum endi ishlamasligini test qulflab qo'ysin (business logic darsidagi "kutilmagan kirish" testi kabi).

Nega o'zi buzib, o'zi yopish. SQL injection maqolasida aytilgani kabi — zaiflikni o'qishning eng foydali usuli uni o'z qo'lingiz bilan ishlatib ko'rish. Buzilgan kodni yozgan odam, uni qayta yozmaydi.

Report uchun talablar#

Zaif ilova: GitHub'da (yoki arxivda) uch zaiflik joylangan Django ilova. Har zaiflik qayerdaligini README'da belgilang.
Hujum: har uch zaiflikni Burp bilan ishga tushirgan skrinshotlar.
Yopish: har zaiflikning oldingi va keyingi kodi. Nega tuzatish ildizni yopadi, yamoq emas — bir jumlada.
Test: har tuzatishga yozilgan test. Test hujum endi ishlamasligini isbotlasin.
Xulosa: bitta abzas — "ishonchsiz ma'lumot ishonchli chegaradan o'tadi" g'oyasini o'z ilovangiz misolida tushuntiring.

Faqat ruxsat berilgan joyda

Bu kursda o'rgangan hamma texnika faqat PortSwigger laboratoriyasida, o'zingiz yozgan ilovada yoki sizga yozma ruxsat berilgan tizimda ishlatiladi. Birovning tizimini ruxsatsiz sinash — natijasidan qat'i nazar, jinoyat. Bu bilimning maqsadi — himoya qurish, buzish emas.

Bundan keyin#

Kurs OWASP Top 10 ning eng muhim qismini qamradi, lekin web xavfsizlik bundan kengroq. Keyingi qadamlar:

OWASP Top 10 ni to'liq ko'rib chiqing — bu saytdagi OWASP Top 10: backend dasturchi uchun tirik qo'llanma.
PortSwigger'ning qolgan bo'limlari: access control (kengroq), JWT hujumlari, GraphQL, web cache poisoning, prototype pollution.
O'z loyihalaringizni har deploy'dan oldin manage.py check --deploy bilan tekshiring; xavfsizlik sarlavhalarini (CSP, HSTS) qo'ying.

Xavfsizlik — bir marta o'rganib bo'ladigan mavzu emas, odat. Har yozgan funksiyada o'sha bitta savolni bering: ishonchsiz ma'lumot qaysi chegaradan o'tyapti, va u tekshirilyaptimi?