Web cache deception — bu zaiflik bo'lib, hujumchiga veb-keshni maxfiy, dinamik kontentni saqlashga aldashga imkon beradi. U kesh serveri va origin server so'rovlarni qanday boshqarishidagi nomuvofiqliklar sababli yuzaga keladi.
Web cache deception hujumida hujumchi jabrlanuvchini zararli URL'ga tashrif buyurishga ko'ndiradi va uning brauzerini maxfiy kontent uchun noaniq (ambiguous) so'rov yuborishga undaydi. Kesh buni statik resurs so'rovi deb noto'g'ri talqin qilib, javobni saqlaydi. Keyin hujumchi xuddi shu URL'ni so'rab, keshlangan javobga (jabrlanuvchining maxfiy ma'lumotiga) ruxsatsiz kiradi.
Web cache deception'ni web cache poisoning'dan farqlash muhim. Ikkalasi ham keshdan foydalansa-da, buni har xil yo'l bilan qiladi:
Web cache poisoning cache key'larni manipulyatsiya qilib, keshlangan javobga zararli kontent kiritadi, keyin u boshqa foydalanuvchilarga beriladi.
Web cache deception cache qoidalaridan foydalanib, keshni maxfiy kontentni saqlashga aldaydi, keyin hujumchi unga kiradi.
Veb-kesh — origin server bilan foydalanuvchi o'rtasida turadigan tizim. Mijoz statik resurs so'raganda, so'rov avval keshga yo'naltiriladi. Agar keshda resurs nusxasi bo'lmasa (cache miss), so'rov origin serverga uzatiladi; javob keshga, so'ng foydalanuvchiga yuboriladi. Kesh javobni saqlashni oldindan sozlangan qoidalar asosida hal qiladi. Kelajakda xuddi shu resurs so'ralganda, kesh saqlangan nusxani to'g'ridan-to'g'ri beradi (cache hit). Keshlash, ayniqsa CDN'lar keng qo'llanishida, veb-kontent yetkazishning muhim qismiga aylangan.
Kesh HTTP so'rov kelganda, uni to'g'ridan-to'g'ri berish mumkin bo'lgan keshlangan javob bor-yo'qligini yoki so'rovni origin serverga uzatish kerakligini hal qilishi kerak. Buni u HTTP so'rov elementlaridan 'cache key' generatsiya qilib qaror qiladi. Odatda bunga URL yo'li va query parametrlari kiradi, lekin sarlavhalar va content type kabi boshqa elementlar ham bo'lishi mumkin. Agar kiruvchi so'rovning cache key'i oldingi so'rovniki bilan mos kelsa, kesh ularni ekvivalent deb hisoblab, keshlangan javob nusxasini beradi.
Cache qoidalari nimani va qancha vaqtga keshlash mumkinligini belgilaydi. Ular ko'pincha statik resurslarni saqlashga sozlangan. Dinamik kontent keshlanmaydi, chunki u maxfiy ma'lumot bo'lishi ehtimoli ko'proq. Web cache deception hujumlari cache qoidalari qanday qo'llanishidan foydalanadi, shuning uchun ba'zi qoida turlarini (ayniqsa URL yo'lidagi belgilangan satrlarga asoslanganlarini) bilish muhim:
.css yoki .js./static yoki /assets.robots.txt va favicon.ico.Umuman olganda, oddiy web cache deception hujumini qurish quyidagi qadamlardan iborat:
GET, HEAD yoki OPTIONS metodlarini qo'llaydigan endpointlarga e'tibor bering.Nomuvofiqliklarni sinash va WCD ekspluatatsiyasini qurishda har bir yuborgan so'rovingiz boshqa cache key'ga ega bo'lishiga ishonch hosil qiling — aks holda sizga keshlangan javoblar berilib, natijalarga ta'sir qiladi. URL yo'li va query parametrlari odatda cache key'ga kirgani uchun, yo'lga har safar o'zgaradigan query string qo'shib key'ni o'zgartirishingiz mumkin. Bu jarayonni Param Miner kengaytmasi bilan avtomatlashtiring.
Testlashda keshlangan javoblarni aniqlay olish muhim. Buning uchun javob sarlavhalari va javob vaqtlariga qarang. X-Cache sarlavhasi javob keshdan berilganini ko'rsatadi:
X-Cache: hit — javob keshdan berildi.X-Cache: miss — kesh so'rov key'i uchun javobga ega emas edi, u origin serverdan olindi (odatda keyin keshlanadi).X-Cache: dynamic — origin server kontentni dinamik generatsiya qildi; odatda keshlashga yaroqsiz.X-Cache: refresh — keshlangan kontent eskirgan, yangilanishi kerak edi.Shuningdek, Cache-Control sarlavhasi keshlashni ko'rsatuvchi direktivaga (masalan public va max-age 0 dan katta) ega bo'lishi mumkin. Bir xil so'rov uchun javob vaqtidagi katta farq ham tezroq javob keshdan berilganini bildirishi mumkin.
Cache qoidalari ko'pincha .css yoki .js kabi keng tarqalgan fayl kengaytmalariga mos kelib statik resurslarni nishonga oladi (ko'p CDN'larda standart xatti-harakat). Agar kesh va origin server URL yo'lini resurslarga moslashda yoki delimiterlardan foydalanishda nomuvofiq bo'lsa, hujumchi origin server e'tibor bermaydigan, lekin kesh ko'radigan statik kengaytmali dinamik resurs so'rovini tuzishi mumkin.
URL yo'lini moslash — URL yo'llarini serverdagi resurslar (fayllar, skriptlar) bilan bog'lash jarayoni. Ikki keng tarqalgan uslub: an'anaviy URL moslash (fayl tizimida to'g'ridan-to'g'ri yo'l) va RESTful URL moslash (yo'llarni API'ning mantiqiy qismlariga abstraktlaydi). Masalan /user/123/profile/wcd.css ni ko'rib chiqing:
/user/123/profile endpointga so'rov deb talqin qilib, wcd.css ni ahamiyatsiz parametr sifatida e'tiborsiz qoldirib, 123-foydalanuvchi profilini qaytaradi./profile katalogidagi wcd.css fayli deb ko'radi. Agar keshda .css bilan tugaydigan so'rovlarni saqlash qoidasi bo'lsa, u profil ma'lumotini CSS fayli kabi keshlab beradi.Origin server yo'lni qanday moslashini sinash uchun nishon endpointga ixtiyoriy yo'l segmentini qo'shing. Masalan /api/orders/123 ni /api/orders/123/foo ga o'zgartirsangiz va javob hali ham buyurtma ma'lumotini qaytarsa, origin server qo'shilgan segmentni e'tiborsiz qoldiradi. Keyin kesh qanday moslashini sinash uchun statik kengaytma qo'shing: /api/orders/123/foo.js. Javob keshlansa, kesh to'liq yo'lni statik kengaytma bilan talqin qiladi va .js uchun cache qoidasi bor.
Delimiterlar URL'lardagi turli elementlar o'rtasidagi chegaralarni belgilaydi. URI RFC ancha erkin bo'lgani uchun freymvorklar orasida farqlar yuzaga keladi. Masalan /profile;foo.css ni ko'rib chiqing: Java Spring ; ni matrix o'zgaruvchilar uchun delimiter sifatida ishlatadi, shuning uchun origin server yo'lni /profile deb kesib, profil ma'lumotini qaytaradi. Ko'p boshqa freymvorklar ; ni delimiter sifatida ishlatmaydi, shuning uchun kesh uni yo'lning bir qismi deb ko'rib, .css qoidasi asosida keshlab qo'yadi.
Ruby on Rails . ni javob formatini belgilash uchun delimiter sifatida ishlatadi; /profile.ico tanilmagan kengaytma bo'lgani uchun standart HTML formatter profil ma'lumotini qaytaradi. OpenLiteSpeed esa kodlangan null %00 ni delimiter sifatida ishlatadi (/profile%00foo.js).
Ekspluatatsiya uchun origin server delimiter sifatida ishlatadigan, lekin kesh ishlatmaydigan belgini toping. Nishon yo'lga ixtiyoriy satr qo'shib (masalan /settings/users/listaaa) ma'lumot to'plang, so'ng ehtimoliy delimiterni sinang (/settings/users/list;aaa). Agar javob asosiy javobga mos kelsa, ; origin server uchun delimiter. Keyin oxiriga statik kengaytma qo'shib, keshni sinang.
Ba'zi parserlar URL'ni qayta ishlashdan oldin ma'lum belgilarni dekodlaydi. Agar delimiter belgi dekodlansa, u delimiter sifatida qaralib, yo'lni kesib qo'yishi mumkin. Kesh va origin server qaysi belgilarni dekodlashidagi farq nomuvofiqlikka olib keladi. Masalan /profile%23wcd.css (kodlangan #): origin server %23 ni # ga dekodlab, yo'lni /profile deb ko'radi; kesh esa %23 ni dekodlamay, .css qoidasi asosida keshlaydi.
Veb-serverlar statik resurslarni ma'lum kataloglarda saqlaydi. Cache qoidalari ko'pincha /static, /assets kabi prefikslarga mos kelib bu kataloglarni nishonga oladi. Bu qoidalar ham WCD'ga zaif bo'lishi mumkin.
Normalizatsiya — URL yo'lining turli ko'rinishlarini standart formatga keltirish (kodlangan belgilarni dekodlash, dot-segmentlarni (../) hal qilish). Kesh va origin server yo'lni qanday normalizatsiya qilishidagi farq hujumchiga har xil talqin qilinadigan path traversal payload tuzishga imkon beradi. Masalan /static/..%2fprofile: origin server slash'ni dekodlab, dot-segmentni hal qilib, yo'lni /profile ga normalizatsiya qiladi; dot-segment hal qilmaydigan kesh esa uni /static/..%2fprofile deb ko'rib, /static prefiksi qoidasi asosida keshlaydi.
Agar origin server kodlangan dot-segmentlarni hal qilsa-yu, kesh qilmasa, quyidagi tuzilishdagi payload bilan ekspluatatsiya qilishga urinishingiz mumkin: /<statik-prefiks>/..%2f<dinamik-yo'l>. Masalan /assets/..%2fprofile — keshga /assets/..%2fprofile, origin serverga esa /profile bo'lib ko'rinadi.
Agar aksincha — kesh server kodlangan dot-segmentlarni hal qilsa-yu, origin server qilmasa — quyidagi tuzilishdan foydalaning: /<dinamik-yo'l>%2f%2e%2e%2f<statik-prefiks>. Bunday holatda path traversal'ning o'zi yetarli emas — statik prefiksga resurs mavjud bo'lishiga erishish kerak.
Ba'zi keshlar javoblarni aniq, to'liq yo'l mosligiga qarab saqlaydi — masalan robots.txt yoki /favicon.ico kabi universal fayllar. Bunday holatda statik kengaytma qo'shib bo'lmaydi, chunki qoida aniq yo'lga bog'langan. Biroq delimiter yoki normalizatsiya nomuvofiqligidan foydalanib, keshga aniq mos keladigan statik yo'l ko'rinsa-yu, origin server dinamik kontent qaytarsa, hujum mumkin bo'ladi.
WCD'ning oldini olish uchun: dinamik javoblarni keshlamang (Cache-Control: no-store yoki private ishlatish); kesh va origin server URL'ni bir xil tarzda tahlil qilishiga (bir xil delimiter, normalizatsiya, moslash qoidalari) ishonch hosil qiling; keshni faqat Content-Type haqiqatan statik resurs bo'lganda saqlaydigan qilib sozlang; iloji bo'lsa keshni haqiqiy statik fayllar bilan cheklang.
