Business logic: tool talab qilmaydigan hujum — tizim dizaynidagi mantiqiy bo'shliqlar

Kursning boshqa hamma darsida bitta texnik naqsh bor edi: maxsus belgi, payload, filtr. Bu dars boshqacha — bu yerda hech qanday texnika yo'q. Zaiflik kodda emas, tizimning mantig'ida: dasturchi jarayon qanday ketishini taxmin qilgan, hujumchi esa boshqacha yo'l topgan.

Business logic zaifligini avtomatik skaner topa olmaydi, chunki har bir so'rov "to'g'ri" ko'rinadi — manfiy son ham son, ikki kupon ham amaldagi kupon. Buni faqat odam topadi, va aynan shuning uchun bu eng qimmatli mahorat: siz tizimni dasturchi o'ylamagan tomondan ko'rasiz.

Bu darsdan keyin siz mantiqiy bo'shliqlarni qidirishni bilasiz, beshta turli xatoni topasiz va nega har bir muhim qoidani serverda tekshirish kerakligini tushunasiz.

Buzilgan taxmin#

Business logic zaifligi bitta umumiy taxmindan tug'iladi:

"Foydalanuvchi jarayonni men dizayn qilgancha bosib o'tadi."

Dasturchi xarid jarayonini chizadi: mahsulot tanla → savatga qo'sh → to'lov → tasdiq. Har qadam avvalgisiga bog'liq deb o'ylaydi. Lekin foydalanuvchi qadamlarni o'zgartirib, takrorlab, teskari bajarishi mumkin — brauzer uni majburlamaydi.

Xato aslida bitta savolni tashlab ketishdan kelib chiqadi: "Agar foydalanuvchi buni qilmasa nima bo'ladi?" Manfiy son kiritsa? Kuponni ikki marta ishlatsa? To'lovni o'tkazib yuborsa? Dasturchi "kim ham unday qilardi" deydi — hujumchi esa aynan shuni qiladi.

Har qoida — serverda tekshirilishi shart: agar tekshiruv faqat brauzerda yoki faqat "odatiy yo'lda" bo'lsa, u tekshiruv emas, taxmin.

Atamalar#

Nazariya: brauzer majburlamaydi#

Zaif qolip — muhim qiymatga yoki qoidaga brauzerda ishonish:

# Zaif: narx mijozdan keladi — brauzer uni "to'g'ri" yuboradi deb ishoniladi
def checkout(request):
    price = int(request.POST["price"])  # <-- mijozdan
    if price <= request.user.credit:
        create_order(request.user, price)

Dasturchi narxni forma yuboradi deb o'ylaydi, chunki brauzerda u yashirin maydon. Lekin 1-darsda ko'rdik: brauzer foydalanuvchining dasturi, u istalgan qiymatni yuboradi. price=1 yuborilsa, server rozi bo'ladi — mantig'i "narx kreditdan kam bo'lsa yetadi", "narx haqiqiymi" emas.

Dizayn:      tanla → narx(server) → to'lov → tasdiq
Hujum:       tanla → narx(MIJOZ o'zgartirdi) → to'lov → tasdiq
                          ▲
                          brauzer majburlamaydi

Amaliyot#

Bu 1-darsdagi taxminning oqibati: narx so'rovda keladi va server unga ishonadi. Narx serverda, bazadan olinishi kerak edi; mijoz faqat qaysi mahsulotni tanlaydi. Bir maydon — butun to'lov mantig'i chetlab o'tildi. Bu IDOR'dagi "so'rovdagi qiymatga ishonma" qoidasining pul versiyasi.

Server narxni to'g'ri hisoblaydi — lekin manfiy miqdorni kutmaydi. Manfiy son jami summani kamaytiradi yoki hatto manfiy qiladi. Dasturchi "miqdor musbat bo'ladi" deb o'ylagan va tekshirmagan. Tashlab ketilgan savol: "agar foydalanuvchi manfiy son kiritsa?"

Manfiy son bloklangan, lekin juda katta son unutilgan. Butun son xotirada chekli — chegaradan oshsa, u eng kichik manfiy songa "aylanadi" (integer overflow). Bu texnik detal, lekin ildizi o'sha mantiqiy bo'shliq: qiymatning chegaralari tekshirilmagan. Musbatni tekshirish yetarli emas — yuqori chegara ham kerak.

Xavfsizlik nazorati bor — admin faqat xodimlarga. Lekin "xodim" ta'rifi o'zgartiriladigan ma'lumotga (email domeni) bog'langan. Bir joyda qattiq nazorat, boshqasida (email o'zgartirish) bo'sh — nazorat nomuvofiq. Hujumchi qattiq eshikni emas, ochiq derazani topadi.

Har kupon "bir marta" degan qoida bor, lekin u faqat ketma-ket bir xil kuponni tekshiradi. Navbatlashtirish holatni "tozalaydi" va qoida qayta qayta ishlaydi. Dasturchi foydalanuvchi kuponlarni navbatlab ishlatishini tasavvur qilmagan. Yana o'sha savol: "agar foydalanuvchi buni kutilmagan tartibda qilsa?"

Nima ishlamaydi va nega#

"Brauzerda tekshiruv qo'ydim." 1-lab: brauzerdagi har qanday tekshiruv Burp bilan chetlab o'tiladi. Brauzer — ishonchsiz tomon. Har qoida serverda takrorlanishi shart.

"Musbat sonni tekshirdim." 2, 3-lab: manfiy bloklangan bo'lsa, juda katta son overflow qiladi. Qiymatning ikki chegarasi ham kerak.

"Har eshikni himoyaladim." 4-lab: bir eshik qattiq, ikkinchisi (email o'zgartirish) ochiq bo'lsa, nazorat nomuvofiq. Himoya eng zaif nuqta qadar kuchli.

Endi yopamiz#

Business logic'ning yechimi bitta kod satri emas — u fikrlash odati. Lekin uni Django'da amalga oshirishning aniq qoidalari bor:

1. Har muhim qiymatni serverda oling yoki tekshiring. Narx, rol, holat — hech qachon mijozdan ishonch bilan olmang:

# Zaif: narx va miqdor mijozdan
price = int(request.POST["price"])
qty = int(request.POST["quantity"])

# To'g'ri: narx bazadan, miqdor tekshirilgan chegarada
product = get_object_or_404(Product, pk=request.POST["product_id"])
qty = int(request.POST["quantity"])
if not (1 <= qty <= 99):  # ikki chegara ham
    raise ValidationError("Miqdor 1 dan 99 gacha")
total = product.price * qty  # narx serverdan

2. Invariantlarni modelda qulflang. "Narx manfiy bo'lmaydi", "miqdor musbat" — bu qoidalarni ma'lumotlar bazasi darajasida majburlang:

from django.core.validators import MinValueValidator
from django.db import models


class OrderItem(models.Model):
    quantity = models.PositiveIntegerField(validators=[MinValueValidator(1)])
    # PositiveIntegerField manfiyni bazada ham rad etadi

3. Ko'p qadamli jarayonni serverda kuzating. Foydalanuvchi qadamni o'tkazib yuborsa, server sezishi kerak — har qadamda oldingi qadam bajarilganini tekshiring, brauzerning "keyingi" tugmasiga ishonmang.

4. Kupon/limit kabi qoidalarni atomik hisoblang. "Bir marta"ni har foydalanuvchi uchun bazada belgilang, navbatlashtirib chetlab bo'lmasin.

Aniq misol: bu saytda holatni o'zgartiruvchi asosiy joy — layk tugmasi (like_toggle). U @require_POST bilan himoyalangan, CSRF token tekshiriladi, rate limiting qo'yilgan, va eng muhimi — qaysi maqolaga layk bosilgani URL yo'lidan (<slug:slug>) olinadi va get_post bilan tekshiriladi, so'rov tanasidagi ishonchsiz qiymatdan emas. Ya'ni "qaysi obyekt" qarori serverda, mijoz faqat mavjud maqolani tanlaydi.

Nazorat savollari#

1. Business logic zaifligi nima uchun avtomatik skaner bilan topilmaydi?
2. Nega brauzerdagi tekshiruv (client-side control) himoya emas?
3. 1-labda narx qayerdan olinishi kerak edi? Nega mijozdan emas?
4. Manfiy miqdor (2-lab) nega o'tib ketdi? Qaysi savol tashlab ketilgan?
5. Integer overflow (3-lab) nima? Nega "musbatni tekshirish" yetarli emas?
6. 4-labda nazorat nega "nomuvofiq"? Qattiq eshik qayerda, ochiq deraza qayerda edi?
7. 5-labda "bir marta" qoidasi qanday chetlab o'tildi?
8. PositiveIntegerField qanday himoya beradi? U qaysi darajada majburlaydi?
9. Ko'p qadamli jarayonni server qanday kuzatishi kerak?
10. "Agar foydalanuvchi buni qilmasa?" savolini test suite'da qanday ifodalaysiz?

Report uchun talablar#

1. Skrinshot: kamida bitta labda "solved" ko'ringan holat.
2. Fikrlash izi: har lab uchun bitta jumla — "dasturchi nimani taxmin qilgan, siz qaysi taxminni buzdingiz?"
3. Nima ishlamadi: biror mantiqiy g'oyani sinadingiz, lekin server tekshirgan ekan — qaysi biri va nega ishlamadi?
4. Tuzatuvchi kod: yuqoridagi zaif checkout funksiyasini oling (yoki o'z loyihangizdan) va uni server tarafida narx + chegara tekshiruvi bilan yoping. Oldingi va keyingi holatni keltiring.

Keyingi dars: kurs yakuni — hamma darsni bitta g'oyaga bog'laymiz va mustaqil sinov loyihasi bilan yopamiz.