الكثير أنظمة الويب حيث تقبل الواجهة الأمامية الاتصالات عبر HTTP / 2 ويمررها إلى الواجهة الخلفية عبر HTTP / 1.1 hتعرضت لنسخة جديدة من هجوم "HTTP Request Smuggling" ، يسمح بإرسال طلبات العملاء المصممة خصيصًا لتقسيم محتوى طلبات المستخدمين الآخرين التي تتم معالجتها في نفس التدفق بين الواجهة الأمامية والخلفية.
الهجوم يمكن استخدامها لإدخال كود JavaScript ضار في جلسة مع موقع شرعي ، تجاوز أنظمة تقييد الوصول واعتراض معلمات المصادقة.
مؤلف الدراسة أظهر إمكانية مهاجمة أنظمة Netflix و Verizon و Bitbucket و Netlify CDN و Atlassian، وحصلت على 56.000 دولار في برامج المكافآت لتحديد نقاط الضعف. تم تأكيد المشكلة أيضًا في منتجات شبكات F5.
المشكلة يؤثر جزئيًا على mod_proxy على خادم Apache http (CVE-2021-33193) ، الإصلاحات المتوقعة في الإصدار 2.4.49 (تم إخطار المطورين بالمشكلة في أوائل مايو واستلموا 3 أشهر لإصلاحها). في nginx ، تم حظر القدرة على تحديد رأسي "طول المحتوى" و "ترميز النقل" في الإصدار السابق (1.21.1).
مبدأ تشغيل الطريقة الجديدة من مطابقة الطلبات في حركة المرور يشبه الثغرة الأمنية التي اكتشفها نفس الباحث قبل عامين، ولكنه يقتصر على الواجهات التي تقبل الطلبات عبر HTTP / 1.1.
استند هجوم "HTTP Request Smuggling" الكلاسيكي على حقيقة أن الواجهات الأمامية والخلفية تفسر استخدام رؤوس HTTP "Content-Length" بشكل مختلف (تحدد الحجم الإجمالي للبيانات في الطلب) و "Transfer-Encoding: chunked" ( يسمح لك بنقل البيانات في أجزاء) ...
على سبيل المثال ، إذا كانت الواجهة تدعم فقط "طول المحتوى" ولكنها تتجاهل "ترميز النقل: مجزأ" ، يمكن للمهاجم إرسال طلب يحتوي على الرؤوس "طول المحتوى" و "ترميز النقل: مجزأ" ، ولكن الحجم ar لا يتطابق "طول المحتوى" مع حجم السلسلة المقطوعة. في هذه الحالة ، ستقوم الواجهة الأمامية بمعالجة الطلب وإعادة توجيهه وفقًا لـ "طول المحتوى" ، وستنتظر الواجهة الخلفية حتى اكتمال الكتلة استنادًا إلى "ترميز النقل: مقسم".
على عكس بروتوكول HTTP / 1.1 النصي ، والذي يتم تحليله على مستوى الخط ، HTTP / 2 هو بروتوكول ثنائي ويتعامل مع الكتل بيانات ذات حجم محدد مسبقًا. ومع ذلك ، HTTP / 2 استخدام الرؤوس الزائفة والتي تتوافق مع رؤوس HTTP العادية. عند التفاعل مع الواجهة الخلفية باستخدام بروتوكول HTTP / 1.1 ، الواجهة الأمامية تترجم هذه الرؤوس الزائفة في رؤوس HTTP / 1.1 HTTP مماثلة. تكمن المشكلة في أن الواجهة الخلفية تتخذ قرارات بشأن تحليل الإرسال استنادًا إلى رؤوس HTTP التي تم تعيينها بواسطة الواجهة الأمامية ، دون معرفة معلمات الطلب الأصلي.
حتى في شكل رؤوس زائفة ، القيم "طول المحتوى" و "ترميز النقل" يمكن دفقها ، على الرغم من عدم استخدامها في HTTP / 2 ، حيث يتم تحديد حجم جميع البيانات في حقل منفصل. ومع ذلك ، عند تحويل طلب HTTP / 2 إلى HTTP / 1.1 ، تمر هذه الرؤوس ويمكن أن تكون مربكة للخلفية.
هناك خياران رئيسيان للهجوم: H2.TE و H2.CL، حيث يتم خداع الواجهة الخلفية بترميز نقل غير صحيح أو قيمة طول محتوى لا تتوافق مع الحجم الفعلي لهيئة الطلب التي تتلقاها الواجهة الأمامية من خلال بروتوكول HTTP / 2.
كمثال على هجوم H2.CL ، تم تحديد حجم غير صحيح في الرأس الزائف طول المحتوى عند تقديم الطلب HTTP / 2 إلى Netflix. يؤدي هذا الطلب إلى إضافة رأس طول محتوى HTTP مشابه عند الوصول إلى الواجهة الخلفية عبر HTTP / 1.1 ، ولكن منذ الحجم في طول المحتوى أقل من الفعلي ، تتم معالجة جزء من البيانات الموجودة في قائمة الانتظار كبداية للطلب التالي.
تمت إضافة أدوات الهجوم بالفعل إلى مجموعة أدوات Burp وهي متوفرة كملحق Turbo Intruder. وكلاء الويب ، وموازن التحميل ، ومسرعات الويب ، وأنظمة تسليم المحتوى ، والتكوينات الأخرى حيث يتم إعادة توجيه الطلبات في مخطط الواجهة الخلفية تكون عرضة للمشكلة.
مصدر: https://portswigger.net