Matteo Collina

قامت الدالة `normalize()` بفك تشفير فواصل السلطة المشفرة بنسبة مئوية داخل مكون المضيف وإعادة إرسالها كفواصل خام أثناء التسلسل. وهذا يسمح بإعادة إرسال مضيف يجمع بين نطاق مسموح به وعلامة @ مشفرة ونطاق مختلف، بحيث تكون علامة @ فاصلًا خامًا لمعلومات المستخدم، مما يؤدي فعليًّا إلى تغيير سلطة عنوان URI إلى النطاق الثاني. يمكن توجيه التطبيقات التي تقوم بتطبيع عناوين URL غير الموثوق بها قبل إجراء فحوصات قائمة المضيفين المسموح بها، أو التحقق من صحة إعادة التوجيه، أو توجيه الطلبات الصادرة، إلى سلطة مختلفة عن تلك المحددة في المدخلات.

تقوم الدالتان `normalize()` و`equal()` بفك تشفير فواصل المسار المشفرة بنظام النسبة المئوية ومقاطع النقاط قبل إجراء عملية إزالة مقاطع النقاط. يؤدي ذلك إلى معاملة بيانات المسار المشفرة على أنها شرطات مائلة فعلية وإشارات إلى الدليل الأصلي، مما يسمح بدمج عناوين URI المختلفة في نفس المسار المعياري. ونتيجة لذلك، قد يتم تجاوز التطبيقات التي تستخدم هذه الدوال لفرض سياسات قائمة على المسار على عناوين URL التي يسيطر عليها المهاجمون، حيث يمكن أن يتحول المسار الذي يبدو محصوراً تحت بادئة مسموح بها إلى موقع مختلف بعد التعيير.

عندما يتم تكوين `trustProxy` بوظيفة ثقة تقييدية، مثل عنوان IP محدد أو شبكة فرعية أو عدد قفزات أو وظيفة مخصصة، فإن دالات الاسترجاع `request.protocol` و`request.host` تقرأان رؤوس `X-Forwarded-Proto` و`X-Forwarded-Host` من أي اتصال، بما في ذلك تلك الواردة من عناوين IP غير موثوق بها. وهذا يسمح للمهاجم الذي يتصل مباشرةً بـ Fastify بتجاوز الوكيل (البروكسي) وتزوير البروتوكول والمضيف اللذين يراهما التطبيق. تؤثر هذه المشكلة على التطبيقات التي تعتمد على `request.protocol` أو `request.host` لاتخاذ قرارات حاسمة من الناحية الأمنية، بما في ذلك فرض استخدام HTTPS، وعلامات ملفات تعريف الارتباط الآمنة، وفحوصات منشأ CSRF، وبناء عناوين URL، والتوجيه القائم على المضيف.

تنشأ المشكلة عندما يقوم أحد التطبيقات بتمرير مدخلات يتحكم فيها المستخدم إلى خيار `upgrade` الخاص بوظيفة `client.request()`. وهذا يسمح للمهاجم بحقن تسلسلات CRLF (Carriage Return Line Feed) (`r `) لإدخال رؤوس HTTP عشوائية أو إنهاء طلبات HTTP قبل الأوان، مما قد يؤدي إلى تهريب البيانات الأولية إلى خدمات غير HTTP مثل Redis وMemcached وElasticsearch. السبب الجذري هو أن undici يكتب قيمة `upgrade` مباشرةً إلى المقبس (socket) دون التحقق من صحة أحرف الرؤوس غير الصالحة. يقع الكود المعرض للخطر في ملف `lib/dispatcher/client-h1.js` في السطر 1121.

يُعتبر Undici عرضة لتفسير غير متسق لطلبات HTTP، وتحديدًا تهريب طلبات/استجابات HTTP. تنشأ المشكلة عند تقديم رؤوس HTTP مكررة لـ `Content-Length` بتنسيق مصفوفة، باستخدام أسماء متباينة في الأحرف الكبيرة والصغيرة (على سبيل المثال، `Content-Length` و`content-length`). ويؤدي ذلك إلى طلبات HTTP/1.1 غير صحيحة تحتوي على قيم `Content-Length` متضاربة. تتأثر التطبيقات التي تستخدم `undici.request()` أو `undici.Client` أو واجهات برمجة تطبيقات (APIs) منخفضة المستوى مماثلة مع تمرير الرؤوس كمصفوفات مسطحة، وكذلك التطبيقات التي تقبل أسماء الرؤوس التي يتحكم فيها المستخدم دون توحيد الأحرف الكبيرة والصغيرة. تشمل العواقب المحتملة «رفض الخدمة» (Denial of Service)، حيث ترفض محللات HTTP الصارمة الطلبات التي تحتوي على رؤوس مكررة، و«تهريب طلبات HTTP» (HTTP Request Smuggling)، والذي يمكن أن يؤدي إلى تجاوز قائمة التحكم في الوصول (ACL)، أو تسميم ذاكرة التخزين المؤقت، أو اختطاف بيانات الاعتماد في عمليات النشر التي تتسم بعدم اتساق تفسير الرؤوس بين الوسطاء والخدمات الخلفية.

يُعتبر عميل undici WebSocket عرضة لحالة «رفض الخدمة» (DoS) بسبب الاستخدام غير المقيد للذاكرة أثناء عملية فك ضغط permessage-deflate. عندما يستخدم اتصال WebSocket ملحق permessage-deflate، يقوم العميل بفك ضغط الإطارات الواردة المضغوطة دون فرض أي قيود على حجم البيانات التي تم فك ضغطها. يمكن لخادم WebSocket ضار إرسال إطار مضغوط صغير، يُعرف باسم «قنبلة فك الضغط»، والذي يتوسع إلى حجم كبير في الذاكرة. قد يؤدي ذلك إلى استنفاد عملية Node.js للذاكرة المتاحة، مما يؤدي إلى تعطل النظام أو عدم استجابته. تكمن المشكلة في الأسلوب `PerMessageDeflate.decompress()`، الذي يقوم بتجميع البيانات التي تم فك ضغطها في الذاكرة دون التحقق مما إذا كان الحجم الإجمالي يتجاوز الحد الآمن.

هذه مشكلة تتعلق باستهلاك الموارد غير المنضبط والتي قد تؤدي إلى هجوم رفض الخدمة (DoS). عند تمكين الدالة `interceptors.deduplicate()` في الإصدارات المعرضة للخطر، قد تتراكم بيانات الاستجابة للطلبات التي تمت إزالة التكرار منها في الذاكرة الخاصة بمعالجات البيانات النهائية. ويمكن لنقطة نهاية أولية غير موثوق بها أو خاضعة لسيطرة المهاجم استغلال هذه الثغرة باستخدام استجابات كبيرة أو مقسمة إلى أجزاء وطلبات متطابقة متزامنة، مما يتسبب في ارتفاع استهلاك الذاكرة واحتمال إنهاء العملية بسبب نفاد الذاكرة (OOM). المستخدمون المتأثرون هم التطبيقات التي تستخدم مانع التكرار الخاص بـ Undici مع نقاط النهاية التي قد تنتج نصوص استجابة كبيرة الحجم أو طويلة الأمد. يتم معالجة المشكلة عن طريق تغيير سلوك إزالة التكرار بحيث يتم دفق أجزاء الاستجابة إلى المعالجات النهائية فور وصولها، بدلاً من تراكم النص الكامل، ومنع إزالة التكرار المتأخرة عندما يكون دفق النص قد بدأ بالفعل.

يمكن أن يرد الخادم بإطار WebSocket يستخدم تنسيق طول 64 بت وقيمة طول كبيرة للغاية. يواجه مكون `ByteParser` داخل undici تجاوزًا في عدد الصحيح أثناء العمليات الحسابية الداخلية، مما يؤدي إلى حالة غير صالحة ويؤدي في النهاية إلى حدوث خطأ فادح من نوع `TypeError` يؤدي إلى إنهاء العملية.

يُعتبر عميل undici WebSocket عرضة لهجوم «رفض الخدمة» (DoS) بسبب عدم كفاية التحقق من صحة المعلمة `server max window bits` ضمن ملحق permessage-deflate. عندما يقوم عميل WebSocket بإنشاء اتصال مع خادم، فإنه يشير تلقائيًا إلى دعمه لضغط permessage-deflate. يمكن لخادم ضار أن يرد بقيمة `server max window bits` تقع خارج النطاق الصالح لـ zlib (8-15). وبالتالي، عندما يرسل الخادم إطارًا مضغوطًا، يحاول العميل إنشاء مثيل لكائن zlib InflateRaw باستخدام قيمة `windowBits` غير صالحة، مما يؤدي إلى حدوث خطأ RangeError متزامن لا يتم معالجته، مما يتسبب في النهاية في إنهاء عملية Node.js. تنشأ هذه المشكلة لأن الدالة `isValidClientWindowBits()` تتحقق فقط من أن القيمة تتكون من أرقام ASCII، دون التأكد من أنها تقع ضمن النطاق المقبول. بالإضافة إلى ذلك، لا يتم تضمين استدعاء `createInflateRaw()` في كتلة try-catch، وينتشر الاستثناء الناتج عبر مكدس الاستدعاءات، مما يؤدي إلى تعطل العملية.

يقوم Fastify بالتحقق من صحة رؤوس `Content-Type` بشكل غير صحيح، حيث يقبل رؤوسًا غير صحيحة تحتوي على أحرف إضافية بعد رمز النوع الفرعي، مما يشكل انتهاكًا لمعيار RFC 9110. وعلى وجه التحديد، يمكن معالجة طلب يحتوي على `Content-Type` مثل ’application/json garbage‘ بدلاً من رفضه مع ظهور الخطأ 415 Unsupported Media Type. عند استخدام محللات نوع المحتوى القائمة على التعبيرات النمطية (regex)، تتم مقارنة القيمة غير الصحيحة مع المحللات المسجلة، مما قد يؤدي إلى توجيه الطلب إلى محلل غير مقصود. وهذا يسمح للمهاجم بالتحايل على التحقق من صحة المحتوى وجعل الخادم يعالج الطلبات ذات أنواع المحتوى غير الصالحة.

Name of the Vulnerable Software and Affected Versions: fastify-csrf versions prior to 3.0.0 Description: The issue affects the fastify-csrf package, where the generated cookie uses insecure defaults and lacks the httpOnly flag, as seen in `cookieOpts: { path: '/', sameSite: true }`. Additionally, the CSRF token is available in the GET query parameter. This set of issues compromises the package's ability to provide CSRF protection. Recommendations: For versions prior to 3.0.0, update to version 3.0.0 or later to resolve the issue. As a temporary workaround, consider setting the httpOnly flag on the cookie and restricting access to the CSRF token in the GET query parameter.

The issue is related to an error in handling HTTP header names, which can be exploited by a remote attacker to cause a denial of service (DoS). This can make the server unable to accept new connections due to delayed requests submission.

The issue is related to improper authorization, where aedes does not respect its own authorization rules when a client sets a `Last Will`. This can lead to publishing a Last Will and Testament (LWT) in a channel even when the client is not authorized.