Ushbu bo'limda server-side request forgery (SSRF) nima ekanini tushuntiramiz, keng tarqalgan misollarni ta'riflaymiz va SSRF zaifliklarini qanday topish hamda ekspluatatsiya qilishni ko'rsatamiz.
Server-side request forgery — bu veb-xavfsizlik zaifligi bo'lib, hujumchiga server tomonidagi ilovani mo'ljallanmagan joyga so'rov yuborishga majbur qilish imkonini beradi. Odatiy SSRF hujumida hujumchi serverni tashkilot infratuzilmasidagi faqat ichki xizmatlarga ulanishga majbur qilishi mumkin. Boshqa hollarda serverni ixtiyoriy tashqi tizimlarga ulanishga majburlab, maxfiy ma'lumot (masalan avtorizatsiya login ma'lumotlari) sizib chiqishiga sabab bo'lishi mumkin.
Muvaffaqiyatli SSRF hujumi ko'pincha tashkilot ichida ruxsatsiz amallar yoki ma'lumotga kirishga olib keladi. Bu zaif ilovada yoki ilova aloqa qila oladigan boshqa back-end tizimlarda bo'lishi mumkin. Ba'zi holatlarda SSRF hujumchiga ixtiyoriy buyruq bajarishga imkon berishi mumkin. Tashqi tizimlarga ulanishga sabab bo'lgan SSRF esa zaif ilovani xosting qiluvchi tashkilotdan kelayotgandek ko'rinadigan zararli hujumlarga olib kelishi mumkin.
SSRF hujumlari ko'pincha ishonch munosabatlaridan (trust relationships) foydalanib, hujumni kuchaytiradi. Bu munosabatlar serverga yoki bir xil tashkilotdagi boshqa back-end tizimlarga nisbatan bo'lishi mumkin.
Serverning o'ziga qarshi SSRF hujumida hujumchi ilovani loopback tarmoq interfeysi orqali ilovani xosting qiluvchi serverga HTTP so'rov yuborishga majbur qiladi. Bu odatda 127.0.0.1 yoki localhost kabi hostname bilan URL berishni o'z ichiga oladi. Masalan, ombor holatini ko'rsatuvchi ilovani ko'rib chiqamiz:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1Hujumchi so'rovni serverga local URL ko'rsatadigan qilib o'zgartirishi mumkin:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://localhost/adminServer /admin URL mazmunini olib, foydalanuvchiga qaytaradi. Odatda admin funksiyasi faqat autentifikatsiya qilingan foydalanuvchilarga ochiq, lekin /admin so'rovi local mashinadan kelsa, odatiy access control chetlab o'tiladi — chunki so'rov ishonchli joydan kelayotgandek ko'rinadi.
Nega ilovalar local mashinadan kelgan so'rovlarga yashirincha ishonadi? Sabablari: access control tekshiruvi ilova serveridan oldin turgan boshqa komponentda amalga oshirilgan bo'lishi mumkin; ofat tiklash (disaster recovery) uchun ilova local mashinadan kelgan har qanday foydalanuvchiga login qilmasdan admin kirish berishi mumkin; admin interfeysi asosiy ilovadan boshqa portda tinglashi mumkin.
Ba'zi hollarda ilova serveri foydalanuvchilar to'g'ridan-to'g'ri yeta olmaydigan back-end tizimlar bilan o'zaro ta'sir qila oladi. Bu tizimlar odatda marshrutlanmaydigan (non-routable) shaxsiy IP manzillarga ega. Ular tarmoq topologiyasi bilan himoyalanganligi sababli ko'pincha zaifroq xavfsizlik holatiga ega. Masalan, back-end URL'da admin interfeysi bo'lsa (http://192.168.0.68/admin), hujumchi quyidagi so'rov bilan unga kirishi mumkin:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://192.168.0.68/adminBa'zi ilovalar 127.0.0.1 va localhost kabi hostname'larni yoki /admin kabi maxfiy URL'larni bloklaydi. Bunday holatda filterni quyidagi usullar bilan chetlab o'tish mumkin:
127.0.0.1ning muqobil IP ko'rinishidan foydalaning: 2130706433, 017700000001 yoki 127.1.127.0.0.1ga resolve bo'ladigan o'z domeningizni ro'yxatdan o'tkazing.Ba'zi ilovalar faqat ruxsat etilgan qiymatlar oq ro'yxatiga mos kiritmalarni qabul qiladi. Bu filterni URL tahlilidagi nomuvofiqliklardan foydalanib chetlab o'tish mumkin:
@ belgisi bilan login ma'lumotlarini joylang: https://expected-host:fakepassword@evil-host.# belgisi bilan URL fragment ko'rsating: https://evil-host#expected-host.https://expected-host.evil-host.Ba'zan filterga asoslangan himoyalarni open redirection zaifligidan foydalanib chetlab o'tish mumkin. Agar ruxsat etilgan domendagi ilova open redirection zaifligiga ega bo'lsa va back-end HTTP so'rov API'si redirectlarni qo'llab-quvvatlasa, filterga mos keladigan, lekin kerakli back-end nishonga redirect qiladigan URL tuzishingiz mumkin:
stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/adminBlind SSRF zaifliklari ilovani berilgan URL'ga back-end HTTP so'rov yuborishga majbur qila olsangiz, lekin back-end so'rovdan kelgan javob ilovaning front-end javobida qaytarilmasa yuzaga keladi. Blind SSRF'ni ekspluatatsiya qilish qiyinroq, lekin ba'zan serverda to'liq masofaviy kod bajarishga (RCE) olib keladi. Batafsil: Blind SSRF zaifliklarini topish va ekspluatatsiya qilish.
Ko'p SSRF zaifliklarini topish oson, chunki ilovaning odatiy trafigi to'liq URL'larni o'z ichiga oladi. Boshqa SSRF misollarini topish qiyinroq:
Referer sarlavhasini loglab, undagi uchinchi tomon URL'lariga tashrif buyuradi. Shu sabab Referer ko'pincha SSRF uchun foydali hujum yuzasidir.