HTTP/2 Bomb يعيد ضغط الذاكرة إلى خريطة الدفاع

مقدمة

تذكّرنا مشكلة حجب الخدمة التي تم الكشف عنها حديثا، والتي تسمى “HTTP/2 Bomb”، بأن أداء الويب الحديث ومتانته غالبا ما يشتركان في نقاط الضعف نفسها. لا يتعلق الأمر بسرقة البيانات أو كسر التشفير. بل يتمثل في إجبار الخوادم على العمل بجهد أكبر ولفترة أطول، إلى أن تبدأ الذاكرة أو سعة المعالجات العاملة في الانهيار.

وتكمن أهمية ذلك في أن HTTP/2 صمم لتحسين طريقة استخدام الاتصالات. فالتعددية المتزامنة، والتحكم في التدفق، وضغط الرؤوس تجعل المواقع أسرع، لكنها أيضا تنشئ حالة يجب على الخوادم والوسطاء العكسيين تتبعها بعناية. وعندما يسيء تقدير هذه الحدود، قد تصبح الإتاحة الحلقة الأضعف.

حقائق سريعة

• يتم تقديم HTTP/2 Bomb على أنه مشكلة حجب خدمة عن بعد، وليس حادثة سرقة بيانات.
• يذكر التقرير nginx وApache httpd وMicrosoft IIS وEnvoy وCloudflare Pingora كأهداف محتملة في الإعدادات الافتراضية.
• لا تزال آلية الهجوم الدقيقة غير مؤكدة في هذه المرحلة، لكن الخطر يتركز على ضغط الموارد على مستوى البروتوكول.
• يستخدم HTTP/2 تدفقات متعددة الإرسال وحالة اتصال يجب على المدافعين تقييدها بإحكام.
• قد يشمل الاحتواء قصير الأمد قيودا أكثر صرامة، ومراقبة، وفي بعض الحالات تقليل التعرض لـ HTTP/2.

المتن

الجزء المثير للاهتمام في هذه الحالة ليس التسمية نفسها، بل الشكل التقني الذي يقف خلفها. يتيح HTTP/2 مرور العديد من الطلبات عبر اتصال واحد، وهو أمر فعال لحركة المرور المشروعة، لكنه يعني أيضا أن عميلا واحدا يمكنه إجبار الخادم على الاحتفاظ بقدر كبير من أعمال المتابعة لكل اتصال. وقد يشمل ذلك إدارة التدفقات، والتعامل مع الرؤوس، وحالة التحكم في التدفق.

من منظور دفاعي، فالعبرة قديمة لكنها عنيدة: ميزات البروتوكول ليست آمنة تلقائيا لمجرد أنها معيارية. وتعامل مواصفة HTTP/2 تحديد الموارد كمتطلب أمني طبيعي، وغالبا ما تعرض التطبيقات أدوات لضبط عدد التدفقات المتزامنة، وعدد الطلبات، وأحجام الرؤوس. وتعرض المنتجات المختلفة هذه الضوابط بطرق مختلفة، لذلك لا ينبغي افتراض أن السلوك الافتراضي موحد بين جميع الموردين.

كما ينبغي قراءة قائمة المنتجات الواردة في الإفصاح بعناية. فهي تشير إلى سطح هجوم واسع عبر خوادم الويب والوكلاء العكسيين، لكن ذلك لا يثبت بحد ذاته تعرضا مماثلا أو أوضاع فشل متطابقة. وبالنسبة إلى IIS وPingora على وجه الخصوص، ينبغي أن تظل الاستنتاجات الخاصة بالمورد مشروطة ما لم يتم التحقق منها بشكل مستقل.

عمليا، يتمثل القلق الرئيسي في تدهور الخدمة: ضغط الذاكرة، أو تجويع المعالجات العاملة، أو استنزاف مجمع الاتصالات. وهذا مهم بشكل خاص عند الحافة، حيث تجمع الوسطاء العكسيون الحركة وتتصدى للموجة الأولى من الإساءة. وإذا كانت حدود HTTP/2 متساهلة، فقد يتمكن المهاجم من إحداث تكلفة غير متناسبة لكل اتصال قبل أن تصبح حدود المعدل العادية ذات فائدة.

حتى وقت كتابة هذا المقال، لم تثبت المعلومات العامة بالكامل السبب التقني الدقيق، أو النطاق الكامل للمستخدمين المتأثرين، أو ما إذا كانت أي أنظمة لاحقة قد تأثرت. تدعم المعلومات المتاحة تحليلا للمخاطر، لا ادعاء قاطعا بوجود اختراق شامل أو إهمال.

الخلاصة

الدرس الأوسع بسيط: ضبط الأداء هو عمل أمني. فكل عملية نشر لـ HTTP/2 تنطوي على مفاضلة بين السرعة والحالة، ويبحث المهاجمون عن النقطة التي تصبح فيها هذه المفاضلة مكلفة. والمدافعون الذين يتعاملون مع إعدادات البروتوكول بوصفها ضابطا من الدرجة الأولى، لا مجرد إعداد خلفي، سيكونون في وضع أفضل لامتصاص محاولة استنزاف الموارد التالية.

ويكيكروك

• HTTP/2: بروتوكول ويب يحسن الأداء عبر حمل عدة طلبات على اتصال واحد.
• التعددية المتزامنة: طريقة لإرسال العديد من التدفقات عبر اتصال شبكة واحد.
• حجب الخدمة (DoS): هجوم يهدف إلى جعل الخدمة غير متاحة عبر استنزاف الموارد.
• ضغط رؤوس HTTP/2 (HPACK): آلية تقلل حمل الرؤوس ويمكن أن تؤثر أيضا في استخدام موارد حالة الاتصال.
• التحكم في التدفق: ميزة بروتوكول تحدد مقدار البيانات التي يمكن إرسالها قبل أن يلحق بها المستقبل.