Muammoning mohiyati shundaki, frontend va backendlar ko'pincha HTTP protokoli uchun turli darajadagi yordamni ta'minlaydi, lekin ayni paytda turli foydalanuvchilarning so'rovlarini umumiy kanalga qamrab oladi. Frontend so'rovlarini qabul qilish va qayta ishlash so'rovlarini ulash uchun uzoq muddatli TCP ulanishi o'rnatiladi, bu orqali foydalanuvchi so'rovlari uzatiladi, zanjir bo'ylab ketma-ket uzatiladi, HTTP protokoli yordamida ajratiladi. So'rovlarni ajratish uchun "Content-Length" (so'rovdagi ma'lumotlarning umumiy hajmini belgilaydi) sarlavhalari va "
Agar frontend faqat "Content-Length" ni qo'llab-quvvatlasa, lekin "Transfer-kodlash: bo'laklangan" ni e'tiborsiz qoldirsa (masalan, Akamai CDN buni qildi) yoki aksincha, muammo yuzaga keladi. Agar Transfer-Encoding: chunked har ikki tomonda ham qo‘llab-quvvatlansa, HTTP sarlavhasini tahlil qilish vositalarining amalga oshirish xususiyatlari hujum uchun ishlatilishi mumkin (masalan, front end “Transfer-Encoding: xchunked”, “Transfer-Encoding: chunked” kabi qatorlarni e’tiborsiz qoldirganda ”, “Transfer-kodlash” :[tab]parchalangan”, “X: X[\n]Transfer-kodlash: bo‘laklangan”, “Transfer-kodlash[\n]: bo‘laklangan” yoki “Transfer-kodlash: bo‘laklangan” va backend ularni muvaffaqiyatli qayta ishlaydi).
Bunday holda, tajovuzkor "Tarkib uzunligi" va "Transfer-kodlash: bo'laklangan" sarlavhalarini o'z ichiga olgan so'rov yuborishi mumkin, ammo "Content-Length" dagi o'lcham parchalangan zanjirning o'lchamiga mos kelmaydi. haqiqiy qiymatdan kichikroq. Agar frontend so'rovni "Content-Length" bo'yicha qayta ishlasa va yo'naltirsa va backend "Transfer-Encoding: chunked" asosida blok tugashini kutsa, u holda "Transfer-kodlash: bo'laklangan" ga asoslangan ma'lumotlarning oxiri bo'ladi. avvalroq aniqlanadi va so'rovning qolgan dumi tajovuzkor keyingi so'rovning boshida bo'ladi, ya'ni. tajovuzkor keyingi uzatiladigan boshqa birovning so'rovining boshiga o'zboshimchalik bilan ma'lumotlarni qo'shishi mumkin bo'ladi.
Amaldagi frontend-backend kombinatsiyasidagi muammoni aniqlash uchun siz frontend orqali shunday so'rov yuborishingiz mumkin:
POST /HTTP haqida/1.1
Xost: example.com
Transfer-kodlash: bo'laklarga bo'lingan
Kontent-uzunligi: 4
1
Z
Q
Agar backend so'rovni darhol qayta ishlamasa va bo'laklangan ma'lumotlarning yakuniy nol chegaralovchi bloki kelishini kutsa, muammo mavjud. To'liqroq tekshirish uchun
Haqiqiy hujumni amalga oshirish hujum qilingan saytning imkoniyatlariga bog'liq, masalan, Trello veb-ilovasiga hujum qilganda, siz so'rovning boshini almashtirishingiz mumkin ("PUT /1/members/1234... x=x&csrf" kabi ma'lumotlarni almashtiring. =1234&username=testzzz&bio=cake”) va uchinchi tomon foydalanuvchisining asl soʻrovi va unda koʻrsatilgan autentifikatsiya cookie-faylini oʻz ichiga olgan xabar yuboring. Saas-app.com saytiga hujum qilish uchun javobda JavaScript kodini so'rov parametrlaridan biriga almashtirish orqali almashtirish mumkin bo'ldi. Redhat.com saytiga hujum qilish uchun tajovuzkorning veb-saytiga yo'naltirish uchun ichki ishlov beruvchi ishlatilgan ("POST /search?dest=../assets/idx?redir=//" shaklidagi so'rov.[elektron pochta bilan himoyalangan]/ HTTP/1.1").
Kontentni etkazib berish tarmoqlari uchun usuldan foydalanish "Xost:" sarlavhasini almashtirish orqali so'ralgan saytni oddiygina almashtirish imkonini berdi. Hujum, shuningdek, kontentni keshlash tizimlarining tarkibini zaharlash va keshlangan maxfiy ma'lumotlarni olish uchun ham ishlatilishi mumkin. Usulning cho'qqisi PayPal-ga hujumni tashkil qilish edi, bu autentifikatsiya paytida foydalanuvchilar tomonidan yuborilgan parollarni ushlab turish imkonini berdi (iframe so'rovi paypal.com/us/gifts sahifasi kontekstida JavaScript-ni bajarish uchun o'zgartirildi, qaysi CSP (Content Security Policy) qo'llanilmagan).
Qizig'i shundaki, 2005 yilda bor edi
Manba: opennet.ru