مشکل اصلی این است که فرانتاندها و بکاندها اغلب سطوح مختلفی از پشتیبانی از پروتکل HTTP را ارائه میکنند، اما در عین حال درخواستهای کاربران مختلف را در یک کانال مشترک کپسوله میکنند. برای اتصال درخواست های دریافت کننده frontend و درخواست های پردازش باطن، یک اتصال طولانی مدت TCP ایجاد می شود که از طریق آن درخواست های کاربر منتقل می شوند، در امتداد زنجیره یکی پس از دیگری منتقل می شوند و با استفاده از پروتکل HTTP از هم جدا می شوند. برای جداسازی درخواستها، سرفصلهای "Content-Length" (اندازه کل دادههای موجود در درخواست را تعیین میکند) و "
مشکل زمانی پیش میآید که فرانتاند فقط از «طول محتوا» پشتیبانی میکند، اما «انتقال-رمزگذاری: تکهشده» را نادیده میگیرد (مثلاً، CDN آکامای این کار را انجام داد) یا برعکس. اگر Transfer-Encoding: chunked در هر دو طرف پشتیبانی می شود، ویژگی های پیاده سازی تجزیه کننده های هدر HTTP را می توان برای حمله استفاده کرد (به عنوان مثال، هنگامی که قسمت جلویی خطوطی مانند "Transfer-Encoding: xchunked"، "Transfer-Encoding: chunked" را نادیده می گیرد. "، "Transfer-Encoding" :[tab]chunked"، "X: X[\n]Transfer-Encoding: chunked"، "Transfer-Encoding[\n]: chunked" یا "Transfer-Encoding: chunked"، و Backend با موفقیت آنها را پردازش می کند).
در این حالت، مهاجم میتواند درخواستی ارسال کند که شامل سرصفحههای «طول محتوا» و «انتقال-رمزگذاری: تکهشده» باشد، اما اندازه در «طول محتوا» با اندازه زنجیره تکهشده مطابقت ندارد. کوچکتر از مقدار واقعی است. اگر فرانتاند درخواست را طبق «Content-Length» پردازش و فوروارد کند و backend منتظر بماند تا بلوک براساس «Transfer-Encoding: chunked» تکمیل شود، آنگاه پایان دادهها براساس «Transfer-Encoding: chunked» خواهد بود. زودتر تعیین شود و دم باقی مانده درخواست مهاجم در ابتدای درخواست بعدی خواهد بود، یعنی. مهاجم میتواند دادههای دلخواه را به ابتدای درخواست شخص دیگری که در مرحله بعدی ارسال میشود، پیوست کند.
برای تعیین مشکل در ترکیب frontend-backend استفاده شده، می توانید درخواستی مانند این را از طریق frontend ارسال کنید:
POST /درباره HTTP/1.1
میزبان: example.com
Transfer-Encoding: تکه تکه شده
طول محتوا: 4
1
Z
Q
این مشکل در صورتی وجود دارد که باطن فوراً درخواست را پردازش نکند و منتظر رسیدن بلوک مرزی صفر نهایی از داده های تکه تکه شود. برای بررسی کاملتر
انجام یک حمله واقعی به قابلیت های سایت مورد حمله بستگی دارد، به عنوان مثال، هنگام حمله به برنامه وب Trello، می توانید شروع درخواست را جایگزین کنید (داده هایی مانند "PUT /1/members/1234... x=x&csrf را جایگزین کنید. =1234&username=testzzz&bio=cake") و پیامی شامل درخواست اصلی یک کاربر شخص ثالث و کوکی احراز هویت مشخص شده در آن ارسال کنید. برای حمله به saas-app.com، مشخص شد که میتوان کد جاوا اسکریپت را در پاسخ با جایگزین کردن آن در یکی از پارامترهای درخواست جایگزین کرد. برای حمله به redhat.com، از یک کنترل کننده داخلی برای هدایت به وب سایت مهاجم استفاده شد (یک درخواست از فرم "POST /search?dest=../assets/idx?redir=//[ایمیل محافظت شده]/ HTTP/1.1").
استفاده از روش شبکه های تحویل محتوا، جایگزینی سایت درخواستی را با جایگزینی هدر "Host:" امکان پذیر کرد. این حمله همچنین می تواند برای مسموم کردن محتویات سیستم های کش محتوا و استخراج داده های محرمانه ذخیره شده مورد استفاده قرار گیرد. اوج روش، سازماندهی حمله به PayPal بود، که امکان رهگیری رمزهای عبور ارسال شده توسط کاربران را در حین احراز هویت فراهم کرد (درخواست iframe برای اجرای جاوا اسکریپت در زمینه صفحه paypal.com/us/gifts تغییر یافت. که CSP (خط مشی امنیت محتوا) اعمال نشد).
جالب اینجاست که در سال 2005 وجود داشت
منبع: opennet.ru