Bu bo'limda ko'p faktorli (multi-factor) autentifikatsiya mexanizmlarida yuzaga kelishi mumkin bo'lgan ayrim zaifliklarni ko'rib chiqamiz. Shuningdek, bu zaifliklardan qanday foydalanishni ko'rsatuvchi bir necha interaktiv laboratoriya beramiz.
Ko'p vebsaytlar foydalanuvchilarni autentifikatsiya qilish uchun faqat parolga tayangan yagona faktorli (single-factor) autentifikatsiyadan foydalanadi. Biroq ba'zilari foydalanuvchidan bir nechta autentifikatsiya faktori bilan shaxsini isbotlashni talab qiladi.
Biometrik faktorlarni tekshirish ko'p saytlar uchun amaliy emas. Biroq "siz biladigan narsa" va "sizda bor narsa"ga asoslangan ikki faktorli autentifikatsiyani (2FA) — majburiy yoki ixtiyoriy — tobora ko'proq uchratish mumkin. Bu odatda foydalanuvchidan an'anaviy parolni ham, qo'lidagi tarmoqdan tashqari (out-of-band) jismoniy qurilmadan olingan vaqtinchalik tasdiqlash kodini ham kiritishni talab qiladi.
Ba'zan hujumchi parol kabi bitta bilimga asoslangan faktorni qo'lga kirita olsa-da, ayni paytda boshqa faktorni tarmoqdan tashqari manbadan olishi ancha kamroq ehtimol. Shu sabab ikki faktorli autentifikatsiya yagona faktorlidan namoyishkorona xavfsizroq. Biroq har qanday xavfsizlik chorasi kabi, u faqat o'z implementatsiyasi darajasida xavfsiz. Yomon joriy qilingan 2FA'ni ham xuddi yagona faktorli autentifikatsiya kabi mag'lub qilish yoki hatto butunlay chetlab o'tish mumkin.
Shuni ham qayd etish kerakki, ko'p faktorli autentifikatsiyaning to'liq foydasi faqat bir nechta turli faktorni tekshirish orqali erishiladi. Bir xil faktorni ikki xil usulda tekshirish haqiqiy ikki faktorli autentifikatsiya emas. Email orqali 2FA — shunday misollardan biri. Foydalanuvchi parol va tasdiqlash kodini kiritishi kerak bo'lsa-da, kodga kirish faqat uning email hisobi login ma'lumotlarini bilishiga tayanadi. Shu sabab bilim faktori aslida ikki marta tekshirilyapti, xolos.
Tasdiqlash kodlarini foydalanuvchi odatda biror jismoniy qurilmadan o'qiydi. Ko'p yuqori xavfsizlikdagi saytlar endi foydalanuvchilarga shu maqsad uchun maxsus qurilma beradi — masalan onlayn-banking yoki ish noutbukingizga kirish uchun ishlatiladigan RSA token yoki keypad qurilma. Xavfsizlik uchun maxsus yasalganidan tashqari, bu qurilmalar tasdiqlash kodini bevosita o'zi generatsiya qilish afzalligiga ham ega. Shuningdek, saytlar shu sabab ko'pincha Google Authenticator kabi maxsus mobil ilovadan foydalanadi.
Boshqa tomondan, ba'zi saytlar tasdiqlash kodlarini foydalanuvchining mobil telefoniga SMS ko'rinishida yuboradi. Bu texnik jihatdan hamon "sizda bor narsa" faktorini tekshirsa-da, suiiste'molga ochiq. Birinchidan, kod qurilmaning o'zi tomonidan generatsiya qilinmay, SMS orqali uzatiladi — bu kodni ushlab olish imkoniyatini yaratadi. Ikkinchidan, SIM almashtirish (SIM swapping) xavfi bor: hujumchi firibgarlik yo'li bilan jabrlanuvchining telefon raqamiga ega SIM karta oladi. Shunda hujumchi jabrlanuvchiga yuborilgan barcha SMS'larni, jumladan tasdiqlash kodini ham oladi.
Ba'zan ikki faktorli autentifikatsiya implementatsiyasi shu darajada buzuq bo'ladiki, uni butunlay chetlab o'tish mumkin.
Agar foydalanuvchidan avval parol, so'ng alohida sahifada tasdiqlash kodi so'ralsa, foydalanuvchi tasdiqlash kodini kiritishdan oldin amalda "login qilingan" holatda bo'ladi. Bu holatda birinchi autentifikatsiya qadamidan keyin to'g'ridan-to'g'ri "faqat login qilinganlar uchun" sahifalarga o'tib bo'lasizmi, sinab ko'rishga arziydi. Ba'zan sayt sahifani yuklashdan oldin ikkinchi qadamni bajarganingizni umuman tekshirmasligini topasiz.
Ba'zan 2FA'dagi buzuq mantiq shuni anglatadiki, foydalanuvchi dastlabki login qadamini bajargandan so'ng, sayt ikkinchi qadamni aynan o'sha foydalanuvchi bajarayotganini yetarlicha tekshirmaydi.
Masalan, foydalanuvchi birinchi qadamda odatdagi login ma'lumotlari bilan kiradi:
POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
...
username=carlos&password=qwertySo'ng ularga hisobiga tegishli cookie beriladi va login jarayonining ikkinchi qadamiga o'tkaziladi:
HTTP/1.1 200 OK
Set-Cookie: account=carlos
GET /login-steps/second HTTP/1.1
Cookie: account=carlosTasdiqlash kodini yuborishda so'rov shu cookie orqali foydalanuvchi qaysi hisobga kirmoqchi ekanini aniqlaydi:
POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=carlos
...
verification-code=123456Bu holatda hujumchi o'z login ma'lumotlari bilan kirishi, so'ng tasdiqlash kodini yuborishda account cookie qiymatini istalgan username'ga o'zgartirishi mumkin.
POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=victim-user
...
verification-code=123456Agar hujumchi shundan keyin tasdiqlash kodini brute-force qila olsa, bu nihoyatda xavfli — chunki bu unga faqat username asosida istalgan foydalanuvchi hisobiga kirish imkonini beradi. Ular foydalanuvchining parolini bilishga umuman muhtoj bo'lmaydi.
Parollar kabi, saytlar 2FA tasdiqlash kodini brute-force qilishning oldini olish choralarini ko'rishi kerak. Bu ayniqsa muhim, chunki kod ko'pincha oddiy 4 yoki 6 xonali son bo'ladi. Yetarli brute-force himoyasi bo'lmasa, bunday kodni buzish arzimas ish.
Ba'zi saytlar buni foydalanuvchi ma'lum sondagi noto'g'ri tasdiqlash kodini kiritsa, uni avtomatik logout qilish orqali oldini olishga urinadi. Amalda bu samarasiz, chunki ilg'or hujumchi bu ko'p qadamli jarayonni ham Burp Intruder uchun makroslar yaratib avtomatlashtira oladi. Xuddi shu maqsadda Turbo Intruder kengaytmasidan ham foydalanish mumkin.