تصبح طبقة السرعة في HTTP/2 فخا للذاكرة
يُظهر نمط جديد موصوف من هجمات حجب الخدمة عن بعد كيف يمكن لضغط الرؤوس والإبقاء على الاتصالات أن يحولا HTTP/2 إلى مشكلة استنزاف للموارد في حزم الويب الرئيسية.
مقدمة
ما يجعل البروتوكول سريعا يمكن أيضا أن يجعله خطيرا. في حالة HTTP/2، يقلل تعدد الإرسال وضغط الرؤوس من الحمل الإضافي على الحركة المرورية الشرعية، ولكنهما يخلقان أيضا حالة أكثر على الخوادم إدارتها. نمط الهجوم الموصوف حديثا باسم “HTTP/2 Bomb” مبني حول هذا التوتر: مدخلات صغيرة على السلك، وعمليات تخصيص كبيرة على الخادم، واتصال يمكن أن يبقى مفتوحا مدة كافية ليواصل الضغط على الذاكرة.
حقائق سريعة
- يوصف HTTP/2 Bomb على أنه مشكلة حجب خدمة عن بعد.
- تمت تسمية NGINX وApache HTTPD وMicrosoft IIS وEnvoy وCloudflare Pingora كمنصات متأثرة.
- تجمع التقنية بين ضغط على نمط HPACK والإبقاء على الاتصالات على غرار Slowloris.
- تشير المعلومات العامة إلى أن عميلا واحدا يمكنه استهلاك ما يصل إلى 32 غيغابايت من الذاكرة على Apache HTTPD وEnvoy في نحو 20 ثانية.
- لدى NGINX وApache HTTPD إصلاحات أو تخفيفات مرتبطة بإصدارات محددة؛ ولم يكن هناك تصحيح متاح وقتها لكل من IIS وEnvoy وCloudflare Pingora.
المتن
على المستوى التقني، يتعلق الأمر هنا أقل بحمولة استغلال مثيرة وأكثر بسوء محاسبة الموارد. يحتفظ HTTP/2 بعدة تدفقات على اتصال واحد، بينما يضغط HPACK الرؤوس لتقليل عرض النطاق. هذا المقايضة أمر طبيعي ومفهوم جيدا، لكنه يعني أيضا أن على التطبيقات تتبع الحالة لكل اتصال بعناية. إذا خصص الخادم الذاكرة مبكرا وأبقاها بينما يظل الاتصال مفتوحا، فيمكن للعميل إحداث ضغط غير متناسب مع القليل جدا من المرور.
الجزء المثير للاهتمام في هذه الحالة هو أن التضخيم لا يُعرض فقط على أنه مشكلة رؤوس كبيرة بشكل كلاسيكي. الآلية المبلّغ عنها تنقل العبء إلى عمليات تخصيص الذاكرة المرتبطة بمعالجة الرؤوس وسلوك التحكم في التدفق. عمليا، يجعل هذا الأمر قضية تتعلق بتوافر الخدمة أكثر من كونه قصة تنفيذ تعليمات برمجية. الأثر المرجح هو البطء أو استنزاف العمال أو التعطل تحت ضغط مستمر، وذلك بحسب كيفية موازنة كل حزمة لموارد HTTP/2.
لهذا السبب يكون الرد الدفاعي معتمدا بشكل كبير على الإعدادات. يتيح NGINX عناصر تحكم في HTTP/2 مثل حدود الرؤوس والطلبات، كما أن mod_http2 في Apache HTTPD يملك مفاتيح خاصة به للتدفقات والذاكرة. وتكتسب هذه الضوابط أهمية لأن مواصفات البروتوكول تحدد الآلية، لا هامش التشغيل الآمن. حيثما تتوفر التحديثات، يكون الترقيع هو الخطوة الأولى؛ وحيث لا تتوفر، قد يحتاج المشغلون إلى التفكير في تقليل التعرض أو تعطيل HTTP/2 مؤقتا على نقاط الدخول الأمامية الحرجة.
حتى وقت كتابة هذا النص، لا تثبت المعلومات العامة بالكامل النطاق التشغيلي الكامل، أو ما إذا كانت كل منصة مذكورة تتصرف بالطريقة نفسها، أو عدد عمليات النشر الواقعية المحمية بحدود غير افتراضية. تدعم المعلومات المتاحة تحليلا للمخاطر، لا ادعاء شاملا بأن جميع خدمات HTTP/2 معرضة للخطر على قدم المساواة.
الخلاصة
الدرس الأوسع بسيط: بروتوكولات الويب الحديثة لا تتعلق بالسرعة فقط، بل بالحالة أيضا. وعندما تكون هذه الحالة مكلفة، لا يحتاج المهاجمون إلى كسر التشفير أو تجاوز المصادقة لإحداث الضرر. كل ما يحتاجون إليه هو أن يجعلوا الخادم ينفق الذاكرة في المكان الخطأ، ولمدة كافية. بالنسبة للمدافعين، يذكر HTTP/2 Bomb بأن ميزات الأداء تستحق نفس التدقيق الذي تستحقه فئات الثغرات الكلاسيكية.
ويكيكروك
- HTTP/2: بروتوكول ويب ثنائي يعدد الكثير من الطلبات عبر اتصال واحد.
- HPACK: نظام ضغط الرؤوس المستخدم في HTTP/2 لتصغير بيانات الطلب والاستجابة الوصفية.
- حجب الخدمة (DoS): هجوم يهدف إلى جعل الخدمة غير متاحة عبر استنزاف الموارد.
- التحكم في التدفق: آلية تحدد مقدار البيانات التي يمكن لنقطة النهاية إرسالها قبل تلقي المزيد من الرصيد.
- Slowloris: أسلوب حجب خدمة على طبقة التطبيق يحافظ على الاتصالات مفتوحة عبر إرسال الطلبات ببطء شديد.




