Ushbu bo'limda quyidagilarni ta'riflaymiz:
Access control (kirishni nazorat qilish) — kim yoki nima amallarni bajarishga yoki resurslarga kirishga ruxsat etilganini cheklashdir. Veb-ilovalar kontekstida access control autentifikatsiya va sessiya boshqaruviga bog'liq:
Buzilgan access control keng tarqalgan va ko'pincha kritik xavfsizlik zaifligidir. Access control dizayni murakkab va dinamik muammo bo'lib, qarorlar odamlar tomonidan qabul qilinadi — shuning uchun xato ehtimoli yuqori.
Vertikal access control maxfiy funksiyaga kirishni muayyan turdagi foydalanuvchilarga cheklaydigan mexanizmdir. Turli foydalanuvchilar turli funksiyalarga kira oladi. Masalan, administrator istalgan foydalanuvchi hisobini o'zgartira yoki o'chira oladi, oddiy foydalanuvchi esa bu amallarga kira olmaydi.
Gorizontal access control resurslarga kirishni muayyan foydalanuvchilarga cheklaydigan mexanizmdir. Turli foydalanuvchilar bir xil turdagi resurslarning bir qismiga kira oladi. Masalan, banking ilovasi foydalanuvchiga o'z hisobidan tranzaksiyalarni ko'rish va to'lov qilishga ruxsat beradi, lekin boshqa foydalanuvchi hisoblariga emas.
Kontekstga bog'liq access control funksiya va resurslarga kirishni ilova holati yoki foydalanuvchining u bilan o'zaro ta'siriga qarab cheklaydi. Masalan, onlayn-do'kon foydalanuvchilarni to'lov qilgandan keyin savat mazmunini o'zgartirishdan to'xtatishi mumkin.
Buzilgan access control zaifliklari foydalanuvchi kira olmasligi kerak bo'lgan resurslarga kirishi yoki bajara olmasligi kerak bo'lgan amallarni bajara olganda mavjud bo'ladi.
Agar foydalanuvchi kirishga ruxsat berilmagan funksiyaga kira olsa, bu vertikal imtiyoz oshirishdir. Masalan, administrator bo'lmagan foydalanuvchi foydalanuvchi hisoblarini o'chira oladigan admin sahifasiga kira olsa, bu vertikal imtiyoz oshirish.
Eng oddiy holatda vertikal imtiyoz oshirish ilova maxfiy funksiyaga hech qanday himoya qo'llamaganda yuzaga keladi. Masalan, admin funksiyalari administrator sahifasidan havola qilingan, lekin oddiy foydalanuvchi sahifasidan emas. Biroq foydalanuvchi tegishli admin URL'ga o'tib, bu funksiyalarga kirishi mumkin:
https://insecure-website.com/adminBu istalgan foydalanuvchiga ochiq bo'lishi mumkin. Ba'zan admin URL boshqa joylarda, masalan robots.txt faylida oshkor bo'ladi. URL hech qayerda oshkor bo'lmasa ham, hujumchi wordlist bilan uni brute-force qilishi mumkin.
Ba'zan maxfiy funksiya kamroq taxmin qilinadigan URL berish orqali yashiriladi (bu "security by obscurity"). Biroq yashirilgan URL foydalanuvchiga sizib chiqishi mumkin — masalan foydalanuvchi roliga qarab UI quradigan JavaScript ichida:
<script>
var isAdmin = false;
if (isAdmin) {
var adminPanelTag = document.createElement('a');
adminPanelTag.setAttribute('href', 'https://insecure-website.com/administrator-panel-yb556');
adminPanelTag.innerText = 'Admin panel';
}
</script>Bu skript URL'ni o'z ichiga oladi va rolidan qat'i nazar barcha foydalanuvchilarga ko'rinadi.
Ba'zi ilovalar foydalanuvchining kirish huquqi yoki rolini login paytida aniqlab, uni foydalanuvchi boshqaradigan joyda (yashirin maydon, cookie, query parametr) saqlaydi va shu qiymatga qarab qaror qabul qiladi:
https://insecure-website.com/login/home.jsp?admin=true
https://insecure-website.com/login/home.jsp?role=1Bu xavfsiz emas, chunki foydalanuvchi qiymatni o'zgartirib, ruxsat etilmagan funksiyaga kira oladi.
Ba'zi ilovalar access control'ni platforma qatlamida, URL va HTTP metodga qarab qo'llaydi. Masalan:
DENY: POST, /admin/deleteUser, managersBa'zi freymvorklar so'rovdagi URL'ni bekor qiladigan nostandart sarlavhalarni (X-Original-URL, X-Rewrite-URL) qo'llab-quvvatlaydi. Agar sayt front-end nazoratini URL asosida qo'llasa, lekin ilova URL'ni sarlavha orqali bekor qilishga ruxsat bersa, access control'ni chetlab o'tish mumkin:
POST / HTTP/1.1
X-Original-URL: /admin/deleteUser
...Boshqa hujum HTTP metodiga tegishli. Ba'zi saytlar amalni bajarishda turli HTTP metodlarga toqat qiladi. Hujumchi cheklangan URL'da amalni bajarish uchun GET (yoki boshqa) metoddan foydalana olsa, platforma qatlamidagi access control'ni chetlab o'tadi.
Saytlar kiruvchi so'rov yo'lini endpoint bilan qanchalik qat'iy moslashtirishda farq qiladi. Masalan, ular /ADMIN/DELETEUSER ni /admin/deleteUser endpointga moslashtirishi mumkin. Agar access control mexanizmi kamroq bag'rikeng bo'lsa, ularni ikki xil endpoint deb qarab, cheklovni qo'llamasligi mumkin. Spring freymvorkida useSuffixPatternMatch yoqilgan bo'lsa, /admin/deleteUser.anything ham mos keladi. Ba'zan yo'l oxiriga slash qo'shib (/admin/deleteUser/) access control'ni chetlab o'tish mumkin.
Gorizontal imtiyoz oshirish foydalanuvchi o'z resurslari o'rniga boshqa foydalanuvchiga tegishli resurslarga kira olganda yuzaga keladi. Masalan, foydalanuvchi o'z hisob sahifasiga quyidagi URL bilan kiradi:
https://insecure-website.com/myaccount?id=123Agar hujumchi id parametrini boshqa foydalanuvchi qiymatiga o'zgartirsa, uning hisob sahifasiga va ma'lumotlariga kirishi mumkin.
Bu insecure direct object reference (IDOR) zaifligiga misol — foydalanuvchi boshqaradigan parametr qiymatlari resurslarga to'g'ridan-to'g'ri kirish uchun ishlatilganda yuzaga keladi.
Ba'zi ilovalarda ekspluatatsiya qilinadigan parametr taxmin qilib bo'lmaydigan qiymatga ega (masalan GUID). Biroq boshqa foydalanuvchilarning GUID'lari ilovaning boshqa joylarida (foydalanuvchi xabarlari yoki sharhlari) oshkor bo'lishi mumkin.
Ba'zan ilova foydalanuvchi resursga kira olmasligini aniqlab, login sahifasiga redirect qaytaradi. Biroq redirect javobi nishondagi foydalanuvchiga tegishli maxfiy ma'lumotni o'z ichiga olishi mumkin, shuning uchun hujum baribir muvaffaqiyatli bo'ladi.
Ko'pincha gorizontal imtiyoz oshirish hujumini imtiyozliroq foydalanuvchini buzish orqali vertikal imtiyoz oshirishga aylantirish mumkin. Masalan, gorizontal oshirish hujumchiga boshqa foydalanuvchi parolini tiklash yoki olishga imkon berishi mumkin. Agar nishon administrator bo'lsa, hujumchi admin huquqlarini oladi:
https://insecure-website.com/myaccount?id=456IDOR — access control zaifliklarining kichik toifasi. IDOR ilova foydalanuvchi bergan kiritmani obyektlarga to'g'ridan-to'g'ri kirish uchun ishlatib, hujumchi kiritmani o'zgartirib ruxsatsiz kira olganda yuzaga keladi. U OWASP 2007 Top Ten'da paydo bo'lishi bilan mashhur bo'lgan.
Ko'p saytlar muhim funksiyalarni bir qator qadamlar orqali amalga oshiradi. Ba'zan sayt bu qadamlarning ayrimlariga qat'iy access control qo'llaydi, lekin boshqalarini e'tibordan chetda qoldiradi. Masalan, access control 1 va 2-qadamlarga to'g'ri qo'llanadi, lekin 3-qadamga emas. Hujumchi dastlabki ikki qadamni o'tkazib yuborib, to'g'ridan-to'g'ri 3-qadamga so'rov yuborib, funksiyaga ruxsatsiz kirishi mumkin.
Ba'zi saytlar access control'ni so'rovda yuborilgan Referer sarlavhasiga asoslaydi. Masalan, ilova /admin sahifasiga access control'ni qat'iy qo'llaydi, lekin /admin/deleteUser kabi sub-sahifalar uchun faqat Referer sarlavhasini tekshiradi. Referer hujumchi tomonidan to'liq boshqarilishi mumkin, shuning uchun u kerakli sarlavhani berib, maxfiy sub-sahifalarga to'g'ridan-to'g'ri so'rov yasashi mumkin.
Ba'zi saytlar access control'ni foydalanuvchining geografik joylashuviga asoslaydi (masalan banking yoki media xizmatlari). Bu nazoratlarni ko'pincha veb-proksilar, VPN yoki client-side geolokatsiya mexanizmlarini manipulyatsiya qilib chetlab o'tish mumkin.
Access control zaifliklarining oldini "defense-in-depth" yondashuvi va quyidagi tamoyillar bilan olish mumkin: