Asosiy login funksiyasidan tashqari, ko'p vebsaytlar foydalanuvchilarga hisobini boshqarish uchun qo'shimcha funksiya beradi. Masalan, foydalanuvchilar odatda parolini o'zgartira yoki unutganda tiklay oladi. Bu mexanizmlar ham hujumchi foydalana oladigan zaifliklarni keltirib chiqarishi mumkin.
Vebsaytlar odatda login sahifalaridagi mashhur zaifliklardan ehtiyot bo'ladi. Biroq shunga o'xshash choralarni bog'liq funksiyalar ham xuddi shunday mustahkam bo'lishini ta'minlash uchun ko'rish kerakligini e'tibordan chetda qoldirish oson. Bu ayniqsa hujumchi o'z hisobini yarata oladigan va, natijada, bu qo'shimcha sahifalarni o'rganishga oson kirish imkoniga ega bo'lgan holatlarda muhim.
Keng tarqalgan funksiya — brauzer sessiyasini yopgandan keyin ham login holatida qolish imkoni. Bu odatda "Remember me" yoki "Keep me logged in" kabi oddiy checkbox bilan amalga oshiriladi.
Bu funksiya ko'pincha biror "remember me" tokenini generatsiya qilib, uni doimiy (persistent) cookie'da saqlash orqali joriy qilinadi. Bu cookie'ga ega bo'lish amalda butun login jarayonini chetlab o'tishga imkon bergani sabab, eng yaxshi amaliyot — bu cookie'ni taxmin qilib bo'lmaydigan qilishdir. Biroq ba'zi saytlar bu cookie'ni statik qiymatlarning (masalan username va vaqt belgisi) oldindan aytsa bo'ladigan birikmasidan generatsiya qiladi. Ba'zilari hatto parolni cookie'ning bir qismi sifatida ishlatadi. Bu yondashuv ayniqsa xavfli, agar hujumchi o'z hisobini yarata olsa — chunki ular o'z cookie'sini o'rganib, uning qanday generatsiya qilinishini aniqlab olishi mumkin. Formulani topgach, boshqa foydalanuvchilarning cookie'sini brute-force qilib, hisoblariga kirishga urinadilar.
Ba'zi saytlar cookie qandaydir tarzda shifrlangan bo'lsa, statik qiymatlardan foydalansa ham taxmin qilib bo'lmaydi deb o'ylaydi. To'g'ri bajarilsa bu rost bo'lishi mumkin, lekin Base64 kabi oddiy ikki tomonlama kodlash bilan cookie'ni sodda "shifrlash" hech qanday himoya bermaydi. Hatto bir tomonlama hash funksiyasi bilan to'g'ri shifrlash ham to'liq daxlsiz emas. Agar hujumchi hash algoritmini oson aniqlay olsa va salt ishlatilmagan bo'lsa, wordlist'larini shunchaki hash qilib cookie'ni brute-force qilishi mumkin. Bu usul bilan, agar cookie taxminlariga o'xshash chegara qo'llanmagan bo'lsa, login urinishi chegaralarini chetlab o'tish mumkin.
Hujumchi o'z hisobini yarata olmasa ham, bu zaiflikdan foydalanishi mumkin. XSS kabi odatiy usullar bilan hujumchi boshqa foydalanuvchining "remember me" cookie'sini o'g'irlab, undan cookie qanday tuzilishini aniqlashi mumkin. Agar sayt ochiq kodli (open-source) freymvork asosida qurilgan bo'lsa, cookie tuzilishining asosiy tafsilotlari hatto ochiq hujjatlashtirilgan bo'lishi mumkin.
Kamdan-kam hollarda cookie'dan foydalanuvchining haqiqiy parolini ochiq matnda (cleartext), hatto u hash qilingan bo'lsa ham, olish mumkin bo'ladi. Mashhur parol ro'yxatlarining hash qilingan versiyalari internetda mavjud, shuning uchun agar foydalanuvchi paroli shunday ro'yxatlardan birida bo'lsa, hashni deshifrlash ba'zan shunchaki hashni qidiruv tizimiga joylashtirish kabi arzimas ish bo'lishi mumkin. Bu samarali shifrlashda salt qanchalik muhimligini ko'rsatadi.
Amalda ba'zi foydalanuvchilar parolini unutadi, shu sabab uni tiklashning bir yo'li bo'lishi keng tarqalgan. Bunday holatda odatdagi parolga asoslangan autentifikatsiya aniq imkonsiz bo'lgani uchun, saytlar haqiqiy foydalanuvchi o'z parolini tiklayotganiga ishonch hosil qilish uchun muqobil usullarga tayanishga majbur. Shu sabab parolni tiklash funksiyasi tabiatan xavfli va uni xavfsiz joriy qilish kerak.
Bu funksiya odatda bir necha xil usulda joriy qilinadi, ular turli darajada zaif bo'ladi.
Aytmasa ham ma'lumki, sayt parollarni dastlab xavfsiz saqlagan bo'lsa, foydalanuvchiga uning joriy parolini yuborish umuman mumkin bo'lmasligi kerak. Buning o'rniga ba'zi saytlar yangi parol generatsiya qilib, uni foydalanuvchiga email orqali yuboradi.
Umuman olganda, doimiy parollarni xavfsiz bo'lmagan kanallar orqali yuborishdan qochish kerak. Bu holatda xavfsizlik yo generatsiya qilingan parolning juda qisqa vaqtdan keyin muddati o'tishiga, yo foydalanuvchi parolini darhol yana o'zgartirishiga tayanadi. Aks holda bu yondashuv man-in-the-middle hujumlariga juda moyil.
Email ham umuman xavfsiz hisoblanmaydi, chunki pochta qutilari ham doimiy, ham maxfiy ma'lumotni xavfsiz saqlash uchun mo'ljallanmagan. Ko'p foydalanuvchilar, shuningdek, pochta qutisini bir necha qurilma o'rtasida xavfsiz bo'lmagan kanallar orqali avtomatik sinxronlaydi.
Parolni tiklashning mustahkamroq usuli — foydalanuvchilarga ularni parolni tiklash sahifasiga olib boradigan unikal URL yuborish. Bu usulning kamroq xavfsiz implementatsiyalari qaysi hisob tiklanayotganini aniqlash uchun oson taxmin qilinadigan parametrli URL ishlatadi, masalan:
http://vulnerable-website.com/reset-password?user=victim-userBu misolda hujumchi user parametrini o'zi aniqlagan istalgan username'ga o'zgartirishi mumkin. Shunda ular to'g'ridan-to'g'ri shu ixtiyoriy foydalanuvchi uchun yangi parol o'rnata oladigan sahifaga o'tkaziladi.
Bu jarayonning yaxshiroq implementatsiyasi — yuqori entropiyali, taxmin qilish qiyin token generatsiya qilib, tiklash URL'ini shunga asoslash. Eng yaxshi holatda bu URL qaysi foydalanuvchining paroli tiklanayotgani haqida hech qanday ishora bermasligi kerak.
http://vulnerable-website.com/reset-password?token=a0ba0d1cb3b63d13822572fcff1a241895d893f659164d4cc550b421ebdd48a8Foydalanuvchi bu URL'ga tashrif buyurganda, tizim bu token back-end'da mavjudligini va, agar bo'lsa, qaysi foydalanuvchining parolini tiklashi kerakligini tekshirishi kerak. Bu token qisqa vaqtdan keyin muddati o'tishi va parol tiklangandan keyin darhol yo'q qilinishi lozim.
Biroq ba'zi saytlar tiklash formasi yuborilganda tokenni qayta tekshirmaydi. Bu holatda hujumchi shunchaki o'z hisobidan tiklash formasiga o'tib, tokenni o'chirib, bu sahifadan foydalangan holda ixtiyoriy foydalanuvchining parolini tiklashi mumkin.
Agar tiklash emailidagi URL dinamik generatsiya qilinsa, bu password reset poisoning'ga ham zaif bo'lishi mumkin. Bunda hujumchi boshqa foydalanuvchining tokenini o'g'irlab, uning parolini o'zgartirish uchun ishlatishi mumkin.
Odatda parolni o'zgartirish joriy parolni, so'ng yangi parolni ikki marta kiritishni o'z ichiga oladi. Bu sahifalar tubdan username va joriy parol mosligini tekshirish uchun oddiy login sahifasi bilan bir xil jarayonga tayanadi. Shu sabab bu sahifalar ham xuddi shunday usullarga zaif bo'lishi mumkin.
Parolni o'zgartirish funksiyasi hujumchiga jabrlanuvchi sifatida login qilmasdan unga to'g'ridan-to'g'ri kirish imkonini bersa, ayniqsa xavfli bo'ladi. Masalan, agar username yashirin (hidden) maydonda berilgan bo'lsa, hujumchi so'rovdagi bu qiymatni tahrirlab, ixtiyoriy foydalanuvchilarni nishonga olishi mumkin. Bundan username enumeration va parollarni brute-force qilish uchun foydalanish mumkin.