أعلنت شركة كلاود فلير عن إصلاح ثلاث ثغرات أمنية في إطار عمل بينجورا، اثنتان منها مصنفتان كخطيرتين (9.3 من 10). بينجورا، وهو إطار عمل مكتوب بلغة رست، مصمم لتطوير خدمات شبكية آمنة وعالية الأداء. يُستخدم خادم وكيل مبني باستخدام بينجورا في شبكة توصيل المحتوى الخاصة بكلاود فلير، ويعالج أكثر من 40 مليون طلب في الثانية. تم إصلاح هذه الثغرات في بينجورا 0.8.0.
تُتيح الثغرتان الأمنيتان الأكثر خطورة تنفيذ هجمات تهريب طلبات HTTP، مما يسمح للمستخدمين بتجاوز أنظمة التحكم في الوصول وحقن شيفرة جافا سكريبت خبيثة في محتوى طلبات المستخدمين الآخرين التي تتم معالجتها في نفس مسار البيانات بين الواجهة الأمامية والخلفية (على سبيل المثال، لإدخال شيفرة جافا سكريبت خبيثة في جلسة مستخدم آخر مع الموقع). وقد اكتشف هذه الثغرات أحد المشاركين في برنامج مكافآت اكتشاف الثغرات الأمنية، الذي يُقدم مكافآت مالية لمن يكتشف هذه الثغرات.
في نظام خلفي قائم على خادم وكيل عكسي، تستقبل عقدة إضافية طلبات العملاء، وتُنشئ اتصال TCP طويل الأمد مع النظام الخلفي الذي يتولى معالجة الطلبات. ينقل هذا الاتصال المشترك عادةً طلبات من مستخدمين مختلفين، يتبع كل منهم الآخر في سلسلة المعالجة، ويفصل بينهما بروتوكول HTTP. تنشأ هجمات تهريب طلبات HTTP من اختلاف تفسيرات رؤوس HTTP ومواصفات بروتوكول HTTP بين الواجهات الأمامية والخلفية، على سبيل المثال، عندما تستخدم الواجهة الأمامية رأس HTTP "Content-Length" لتحديد حجم الطلب، بينما يستخدم النظام الخلفي "Transfer-Encoding: chunked".
تكمن الثغرة الأمنية الأولى، CVE-2026-2835، في كود تحليل طلبات HTTP/1.0، وتنتج عن معالجة غير صحيحة لعنوان "Transfer-Encoding" عند وجود قيم متعددة، بالإضافة إلى استخدام إغلاق الاتصال كنهاية للطلب (close-delimited). كان برنامج Pingora يتحقق فقط من خيار "Transfer-Encoding: chunked" ويتجاهل هذا العنوان إذا احتوى على قيم متعددة. في هذه الحالة، تجاهل Pingora حجم البيانات في عنوان "Content-Length" واعتبر جميع البيانات المستلمة قبل إغلاق الاتصال بمثابة نص الطلب.
من خلال تحديد قيم متعددة في ترويسة "Transfer-Encoding"، يستطيع المهاجم تهيئة ظروف يتم فيها توجيه طلب إلى الخادم الخلفي بحجم فعلي لا يتطابق مع حجم سلسلة البيانات المجزأة المحسوب بناءً على ترويسة "Transfer-Encoding". قام Pingora بتوجيه جميع البيانات المستلمة كطلب واحد، وقام الخادم الخلفي، على سبيل المثال Node.js، بحساب الطلب بناءً على "Transfer-Encoding: chunked" ومعالجة الجزء المتبقي كبداية لطلب آخر. GET / HTTP/1.0 Host: example.com Connection: keep-alive Transfer-Encoding: identity, chunked Content-Length: 29 0 GET /admin HTTP/1.1 X:
الثغرة الأمنية الثانية، CVE-2026-2833، ناتجة عن معالجة غير صحيحة لعنوان HTTP "Upgrade" في طلبات HTTP/1.1. عند وجود عنوان "Upgrade" في الطلب، يقوم الخادم الوسيط (Proxy) بإعادة توجيه بيانات الطلب المتبقية مباشرةً إلى الخادم الخلفي (Backend) دون انتظار رد الخادم الخلفي برمز 101 (تبديل البروتوكولات). يؤدي هذا إلى تعطيل تزامن تدفق البيانات بين الخادم الوسيط والخادم الخلفي، مما يجعل الخادم الخلفي يتعامل مع البيانات المرسلة بعد عنوان "Upgrade" كطلب منفصل، ويرسل نتيجة هذا الطلب كرد على طلب لاحق من مستخدم آخر. GET / HTTP/1.1 Host: example.com Upgrade: foo GET /admin HTTP/1.1 Host: example.com
تظهر المشكلات عند استخدام Pingora كخادم وسيط للدخول، حيث يقوم بتوجيه طلبات المستخدمين إلى الخوادم الخلفية باستخدام بروتوكولي HTTP/1.0 أو HTTP/1.1. وقد حال تكوين Pingora المستخدم في شبكة توصيل المحتوى Cloudflare دون استغلال هذه الثغرات، إذ لا يُستخدم Pingora كخادم وسيط للدخول في شبكة توصيل المحتوى، ويقوم بتوجيه الطلبات باستخدام بروتوكول HTTP/1.1 فقط، ويحظر الطلبات التي تحتوي على قيم Content-Length غير صحيحة، ويوجه قيمة واحدة فقط لرأس "Transfer-Encoding: chunked"، ويُضيف رأس "Connection: close" إلى الطلبات التي تحتوي على رأس "Upgrade:"، مما يمنع إرسال طلبات إضافية عبر نفس الاتصال.
تُسبب الثغرة الأمنية الثالثة، CVE-2026-2836 (خطورتها 8.4 من 10)، تسميم ذاكرة التخزين المؤقت نتيجةً لإنشاء مفتاح تخزين مؤقت (CacheKey) استنادًا إلى مسار URI فقط، متجاهلةً محتوى ترويسة "Host". يؤدي هذا الخلل إلى إنشاء مفاتيح تخزين مؤقت متطابقة لمسارات HTTP متطابقة إلى مضيفين مختلفين. يمكن استغلال هذه الثغرة لتزييف محتوى ذاكرة التخزين المؤقت عند استخدام التخزين المؤقت متعدد المضيفين. يُعد التخزين المؤقت ميزة تجريبية في Pingora، ولا يُنصح باستخدامه في بيئات الإنتاج.
المصدر: opennet.ru
