Business logic zaifliklari yuzaga keladigan kontekstga nisbatan o'ziga xos. Biroq logic flaw'larning alohida holatlari juda farq qilsa-da, ular ko'plab umumiy mavzularni bo'lishishi mumkin. Ushbu bo'limda dizayn va ishlab chiqish jamoalari qiladigan ba'zi tipik xatolarni ko'rib chiqamiz va ular business logic flaw'larga qanday bevosita olib kelishini ko'rsatamiz.
Logic flaw'lar misollariga quyidagilar kiradi:
Tubdan noto'g'ri taxmin — foydalanuvchilar ilova bilan faqat berilgan veb-interfeys orqali muloqot qiladi degan fikr. Bu ayniqsa xavfli, chunki bu o'z navbatida client-side tekshiruv foydalanuvchilarni zararli kiritma yuborishdan to'xtatadi degan qo'shimcha taxminga olib keladi. Biroq hujumchi shunchaki Burp Proxy kabi vositalar bilan ma'lumot brauzer tomonidan yuborilgandan keyin, lekin server tomonidagi logikaga o'tishdan oldin uni o'zgartirishi mumkin. Bu esa client-side nazoratlarni amalda foydasiz qiladi.
Ilova logikasining maqsadlaridan biri — foydalanuvchi kiritmasini biznes qoidalariga mos qiymatlar bilan cheklash. Ko'p ilovalar logikasiga raqamli chegaralar kiritadi. Bunga inventarni boshqarish, byudjet cheklovlarini qo'llash kabi chegaralar kirishi mumkin.
Oddiy onlayn-do'kon misolini olaylik. Mahsulotlarga buyurtma berishda foydalanuvchilar odatda kerakli miqdorni ko'rsatadi. Nazariy jihatdan har qanday butun son haqiqiy kiritma bo'lsa-da, business logic foydalanuvchilarni hozirda omborda mavjud bo'lgandan ko'proq birlik buyurtma qilishdan to'xtatishi mumkin.
Masalan, raqamli ma'lumot turi manfiy qiymatlarni qabul qilishi mumkin. Agar ilova yetarli server tomonidagi tekshiruvni amalga oshirmasa va bu kiritmani rad etmasa, hujumchi manfiy qiymat berib, kerakmas xatti-harakatni yuzaga keltirishi mumkin. Ikki bank hisobi o'rtasidagi mablag' o'tkazmasini ko'rib chiqing. Bu funksiya deyarli har doim o'tkazmani yakunlashdan oldin yuboruvchida yetarli mablag' borligini tekshiradi:
$transferAmount = $_POST['amount'];
$currentBalance = $user->getBalance();
if ($transferAmount <= $currentBalance) {
// O'tkazmani yakunlash
} else {
// O'tkazmani bloklash: mablag' yetarli emas
}Agar logika foydalanuvchilarni amount parametrida manfiy qiymat berishdan yetarlicha to'xtatmasa, buni hujumchi balans tekshiruvini chetlab o'tish va mablag'ni "noto'g'ri" yo'nalishda o'tkazish uchun ekspluatatsiya qilishi mumkin. Agar hujumchi jabrlanuvchi hisobiga -$1000 yuborsa, natijada u jabrlanuvchidan $1000 olishi mumkin. Logika har doim -1000 joriy balansdan kichik deb baholaydi va o'tkazmani tasdiqlaydi.
Ilovani auditdan o'tkazayotganda Burp Proxy va Repeater kabi vositalardan foydalanib noodatiy qiymatlarni yuborib ko'ring. Ayniqsa qonuniy foydalanuvchilar hech qachon kiritmasi ehtimoldan yiroq diapazondagi kiritmalarni sinang: juda katta yoki juda kichik raqamli kiritmalar va matn maydonlari uchun g'ayritabiiy uzun satrlar. Kutilmagan ma'lumot turlarini ham sinab ko'rishingiz mumkin.
Logic zaifliklarining eng keng tarqalgan ildiz sabablaridan biri — foydalanuvchi xatti-harakati haqida noto'g'ri taxminlar qilish.
Ba'zi ilovalar biznes qoidalarini ta'minlash uchun mustahkam ko'rinadigan choralarni joriy qilgani uchun xavfsiz ko'rinishi mumkin. Afsuski, ayrim ilovalar bu qat'iy nazoratlardan dastlab o'tgach, foydalanuvchi va uning ma'lumotiga cheksiz ishonish mumkin deb xato qiladi. Agar biznes qoidalari va xavfsizlik choralari ilova bo'ylab izchil qo'llanmasa, bu hujumchi ekspluatatsiya qilishi mumkin bo'lgan xavfli teshiklarga olib kelishi mumkin.
Bir noto'g'ri tushuncha — foydalanuvchilar majburiy kiritma maydonlariga har doim qiymat beradi degan fikr. Brauzerlar oddiy foydalanuvchilarni kerakli kiritmasiz formani yuborishdan to'xtatishi mumkin, lekin hujumchilar parametrlarni yo'lda o'zgartirishi mumkin. Bu hatto parametrlarni butunlay olib tashlashgacha boradi. Logic flaw'larni qidirayotganda har bir parametrni navbatma-navbat olib tashlab, bu javobga qanday ta'sir qilishini kuzating.
Ko'p tranzaksiyalar bir qator qadamlardan iborat oldindan belgilangan ish oqimlariga tayanadi. Veb-interfeys odatda foydalanuvchini bu jarayon bo'ylab yetaklaydi. Biroq hujumchilar bu mo'ljallangan ketma-ketlikka albatta amal qilmaydi. Bu ehtimolni hisobga olmaslik ekspluatatsiya qilish nisbatan oson bo'lgan xavfli kamchiliklarga olib kelishi mumkin. Masalan, ko'p 2FA joriy qilgan saytlar foydalanuvchidan bir sahifada login qilib, so'ng alohida sahifada tasdiqlash kodini kiritishni talab qiladi. Foydalanuvchilar bu jarayonni doim oxirigacha bajaradi deb taxmin qilish hujumchilarga 2FA qadamini butunlay chetlab o'tishga imkon berishi mumkin.
Bunday kamchiliklarni aniqlash uchun forced browsing yordamida so'rovlarni mo'ljallanmagan ketma-ketlikda yuboring. Masalan, ayrim qadamlarni o'tkazib yuborishingiz, bitta qadamga bir necha marta kirishingiz yoki oldingi qadamlarga qaytishingiz mumkin.
LabKo'p hollarda biznes sohasiga yoki sayt maqsadiga xos logic flaw'larga duch kelasiz. Onlayn-do'konlarning chegirma funksiyasi logic flaw ovlashda klassik hujum yuzasidir. Masalan, $1000 dan oshgan buyurtmalarga 10% chegirma beradigan onlayn-do'konni ko'rib chiqing. Agar business logic chegirma qo'llanilgandan keyin buyurtma o'zgartirilganini tekshirmasa, bu suiiste'molga zaif bo'lishi mumkin. Hujumchi savatiga $1000 chegarasiga yetguncha mahsulot qo'shib, so'ng buyurtma berishdan oldin kerakmas mahsulotlarni olib tashlashi mumkin. Shunda ular endi mezonga javob bermasa ham chegirmani oladi.
Foydalanuvchi boshqaradigan kiritma shifrlangan va hosil bo'lgan shifrmatn (ciphertext) foydalanuvchiga biror tarzda taqdim etilganda xavfli holatlar yuzaga kelishi mumkin. Bunday kiritma ba'zan "encryption oracle" deb ataladi. Hujumchi bundan foydalanib, to'g'ri algoritm va kalit bilan ixtiyoriy ma'lumotni shifrlashi mumkin. Bu ilovada xuddi shu algoritm bilan shifrlangan ma'lumot kutadigan boshqa foydalanuvchi boshqaradigan kiritmalar bo'lsa, xavfli bo'ladi — hujumchi orakuldan foydalanib haqiqiy, shifrlangan kiritma yaratib, uni boshqa maxfiy funksiyalarga uzatishi mumkin.
Ba'zi vebsaytlar email manzillarini tahlil qilib, domenni ajratadi va email egasi qaysi tashkilotga tegishli ekanini aniqlaydi. Bu jarayon dastlab oddiy ko'rinsa-da, hatto haqiqiy RFC'ga mos manzillar uchun ham juda murakkab. Email manzillari qanday tahlil qilinishidagi nomuvofiqliklar bu logikani buzishi mumkin. Hujumchi bu nomuvofiqliklardan email manzilining qismlarini yashirish uchun kodlash usullaridan foydalanib ekspluatatsiya qilishi mumkin — bu unga dastlabki tekshiruvlardan o'tadigan, lekin server parseri boshqacha talqin qiladigan email manzillari yaratishga imkon beradi.
Email parser nomuvofiqliklarining asosiy ta'siri — ruxsatsiz kirish. Hujumchilar cheklangan domenlardan ko'rinishidan haqiqiy email manzillari bilan hisob ochib, ilovaning admin panellari kabi maxfiy qismlariga kirishi mumkin.
Lab