Ushbu bo'limda keshlash tizimlarining muayyan implementatsiyalaridagi g'alizliklardan foydalanib, WCP uchun ancha kattaroq hujum yuzasiga qanday kirishni ko'rsatamiz. Ayniqsa, cache key qanday generatsiya qilinishidagi kamchiliklar ba'zan an'anaviy "ekspluatatsiya qilib bo'lmaydigan" deb hisoblangan zaifliklar orqali saytlarni zaif qoldirishni ko'rib chiqamiz.
Request line odatda cache key'ning qismi bo'lgani uchun URL yo'li va query string an'anaviy WCP uchun mos emas deb hisoblangan. Biroq amalda ko'p sayt va CDN'lar cache key'ga saqlaganda kalitli komponentlarga turli transformatsiyalar qiladi: query string'ni chiqarish, muayyan parametrlarni filtrlash, kiritmani normalizatsiya qilish. Bu transformatsiyalar cache key'ga yozilgan ma'lumot bilan ilova kodiga uzatiladigan ma'lumot o'rtasida farqlarni keltirib chiqaradi — bulardan keshni dastlab yaroqsiz ko'ringan kiritmalar orqali zaharlashda foydalanish mumkin.
Metodologiya: mos "cache oracle" (kesh xatti-harakati haqida fikr beruvchi sahifa) topish; key boshqaruvini sinash; ekspluatatsiya qilinadigan gadget topish. Ba'zi keshlar cache key'ni to'g'ridan-to'g'ri ko'rsatadi — masalan Akamai Pragma: akamai-x-get-cache-key sarlavhasini qo'llab-quvvatlasa, javob sarlavhalarida X-Cache-Key ko'rsatiladi.
Ba'zi keshlash tizimlari Host sarlavhasini tahlil qilib, portni cache key'dan chiqaradi. Bunday holatda redirect URL Host asosida generatsiya qilinsa, so'rovga ixtiyoriy port qo'shib DoS hujumini qurish mumkin. Sayt raqamli bo'lmagan portga ruxsat bersa, XSS payload inyeksiya qilish mumkin.
Eng keng tarqalgan transformatsiyalardan biri — butun query string'ni cache key'dan chiqarish. Bu dinamik sahifalarni statik kabi ko'rsatib qo'yadi. Cache buster'ni kalitli sarlavhaga qo'shish mumkin (masalan Accept-Encoding: gzip, deflate, cachebuster). Query string'ni chiqarish reflected XSS'ni yashirishi, lekin uni yanada jiddiyroq qilishi ham mumkin — payload odatiy URL'ga kirgan barchaga beriladi.
Ba'zi saytlar butun query string emas, faqat muayyan parametrlarni (masalan analitika uchun utm_content kabi UTM parametrlari) cache key'dan chiqaradi. Ba'zi sahifalar butun URL'ni zaif tarzda boshqarsa, ixtiyoriy parametrlarni ekspluatatsiya qilish mumkin.
Agar kesh URL'ni tahlil qilib keraksiz parametrlarni olib tashlasa, kesh va ilova o'rtasidagi tahlil farqlaridan foydalanib, ixtiyoriy parametrlarni "yashirib" (cloak) ilova mantiqiga kiritish mumkin. Masalan, GET /?example=123?excluded_param=bad-stuff-here — kesh ikki parametr ko'rib, ikkinchisini chiqaradi, lekin server faqat birinchi ? ni ajratuvchi deb ko'rib, butun qolgan qismni example qiymati deb qabul qiladi. Ruby on Rails ; ni ham ajratuvchi deb qabul qilsa, kalitli parametr qiymatini override qilish mumkin.
Ba'zan HTTP metod kalitsiz bo'ladi. Bu keshni tanada (body) zararli payloadli POST so'rov bilan zaharlashga imkon berishi mumkin. Ba'zan GET so'rovga tana qo'shib "fat GET" yaratish mumkin:
GET /?param=innocent HTTP/1.1
...
param=bad-stuff-hereBunda cache key request line asosida bo'ladi, lekin parametrning server tomonidagi qiymati tanadan olinadi. X-HTTP-Method-Override: POST sarlavhasi bilan "fat GET" boshqaruvini rag'batlantirish mumkin.
Cache key'ga qo'llangan har qanday normalizatsiya ekspluatatsiya qilinadigan xatti-harakat keltirib chiqarishi mumkin. Reflected XSS ko'pincha amalda ekspluatatsiya qilib bo'lmaydi, chunki brauzerlar kerakli belgilarni URL-kodlaydi. Lekin ba'zi keshlar kalitli kiritmani cache key'ga qo'shganda normalizatsiya qiladi — shunda /example?param="><test> va /example?param=%22%3e%3ctest%3e bir xil key'ga ega bo'ladi. Bu bunday "ekspluatatsiya qilib bo'lmaydigan" XSS'ni ekspluatatsiya qilishga imkon beradi — keshni kodlanmagan payload bilan zaharlaysiz, jabrlanuvchi brauzeri URL-kodlasa ham, kesh normalizatsiya qilgandan keyin bir xil key bo'ladi.
Ba'zan kalitli sarlavhada client-side zaiflik topasiz. Kalitli komponentlar cache key yaratish uchun bitta satrga birlashtiriladi. Agar kesh komponentlar orasidagi ajratuvchilarni to'g'ri escape qilmasa, bir xil cache key'ga ega ikki xil so'rov tuzish mumkin — bu "ekspluatatsiya qilib bo'lmaydigan" muammoni ekspluatatsiya qilishga imkon beradi.
To'liq integratsiyalashgan, ilova darajasidagi (application-level) keshlar g'alizliklari yanada kuchli bo'lishi mumkin. Ichki keshlar shunchalik oldindan aytib bo'lmaydigan bo'lishi mumkinki, ularni jonli foydalanuvchilar uchun beixtiyor zaharlamasdan sinash qiyin.