Ulises Gascón

تفشل البرمجيات الوسيطة للتسجيل في تحييد أحرف التحكم عندما يستخرج الرمز المميز `:remote-user` اسم المستخدم الخاص بالمصادقة الأساسية من رأس طلب التفويض. يمكن لمهاجم غير مصدق إرسال رأس تفويض أساسي مُصمم خصيصًا يحتوي على بايتات إرجاع العربة (CR) أو تغذية السطر (LF) لإدخال أسطر سجل مزورة. يؤدي هذا إلى كسر بنية ”طلب واحد لكل سطر“ في سجلات الوصول، مما يتيح تزوير السجلات ضد مستهلكي السجلات في المراحل اللاحقة. تؤثر هذه المشكلة على التنسيقات المدمجة والعامة والافتراضية والمختصرة المضمنة، بالإضافة إلى أي تنسيق مخصص يشير إلى `:remote-user`.

يحدث هجوم «رفض الخدمة» (DoS) بسبب استثناء لم يتم التقاطه أثناء تحليل طلبات `multipart/form-data`. عندما يحتوي الطلب على رأس `Content-Disposition` مع معلمة `filename*` التي تتميز بترميز مئوي غير صحيح، يقوم المحلل باستدعاء الدالة `decodeURI()` بدون كتلة try/catch. يؤدي هذا إلى حدوث خطأ `URIError` الذي يتسبب في تعطل العملية، مما يؤثر على أي خدمة تقبل عمليات التحميل متعددة الأجزاء عبر هذه المكتبة.

تحدث حالة «رفض الخدمة» (DoS) عند إرسال طلب من نوع multipart/form-data يحتوي على اسم حقل يتعارض مع خاصية موروثة من Object.prototype، مثل ` proto ` أو `constructor` أو `toString`. يؤدي هذا إلى قيام المحلل باستدعاء الدالة `.push()` على قيمة النموذج الأولي الموروثة بدلاً من المصفوفة، مما ينتج عنه خطأ TypeError الذي يؤدي إلى استثناء لم يتم التقاطه وتعطل العملية. تؤثر هذه المشكلة على أي خدمة تقبل عمليات التحميل متعددة الأجزاء عبر multiparty.

توجد مشكلة رفض الخدمة (DoS) ناتجة عن عملية التراجع في التعبير النمطي (regular expression) في محلل معلمة اسم الملف Content-Disposition. يمكن أن يتسبب تحميل متعدد الأجزاء مصمم خصيصًا يحتوي على قيمة رأس طويلة في استغراق مطابقة التعبير النمطي عدة ثوانٍ، مما يؤدي إلى حظر حلقة الأحداث. ويؤثر هذا على أي خدمة تقبل عمليات التحميل المتعددة الأجزاء باستخدام هذه المكتبة.

يحدث الكشف عن شفرة المصدر عبر الأصول المختلفة عند تقديم الخدمة عبر أصل غير موثوق به، مثل بروتوكول HTTP العادي. تنشأ المشكلة لأن الإصلاح السابق اعتمد على رؤوس طلبات `Sec-Fetch-Mode` و`Sec-Fetch-Site`، والتي تتجاهلها المتصفحات في حالة الأصول غير الموثوق بها. وهذا يسمح لموقع ضار بتحميل المصدر المجمّع كنص برمجي وقراءته عبر الأصول المختلفة. يمكن للمهاجم الذي يتحكم في موقع ويب يزوره أحد المطورين استرداد شفرة المصدر للتطبيق إذا كان الخادم يعمل عبر بروتوكول HTTP على مضيف ومنفذ يمكن تخمينهما. لا تتأثر المتصفحات المستندة إلى Chromium بدءًا من الإصدار Chrome 142 فصاعدًا بسبب قيود الوصول إلى الشبكة المحلية.

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

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

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

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

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

يُعتبر عميل 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، وينتشر الاستثناء الناتج عبر مكدس الاستدعاءات، مما يؤدي إلى تعطل العملية.

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

يُعتبر 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()`، الذي يقوم بتجميع البيانات التي تم فك ضغطها في الذاكرة دون التحقق مما إذا كان الحجم الإجمالي يتجاوز الحد الآمن.

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

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

يوجد ثغرة أمنية في Multer، وهو برنامج وسيط (middleware) لـ Node.js يُستخدم لمعالجة `multipart/form-data`. يمكن استغلال هذه المشكلة لإحداث هجوم رفض الخدمة (DoS) عن طريق إرسال طلبات مصممة خصيصًا لهذا الغرض، مما قد يؤدي إلى حدوث تجاوز سعة المكدس (stack overflow).

البرنامج معرض لحدوث حالة رفض الخدمة (DoS) ناجمة عن المعالجة غير الفعالة لنصوص الطلبات المشفرة في عناوين URL التي تحتوي على عدد كبير من المعلمات. يمكن للمهاجم استغلال هذه الثغرة عن طريق إرسال طلبات تحتوي على آلاف المعلمات ضمن الحد الأقصى لحجم الطلب البالغ 100 كيلوبايت، مما يؤدي إلى زيادة استهلاك وحدة المعالجة المركزية (CPU) والذاكرة. وقد يتسبب ذلك في تدهور الخدمة أو تعطلها عند تعرضها لحركة مرور ضارة مستمرة.

اسم البرنامج المعرض للخطر والإصدارات المتأثرة Lodash الإصدارات من 4.0.0 إلى 4.17.22 الوصف الإصدارات من 4.0.0 إلى 4.17.22 من Lodash معرضة لثغرة «تلوث النموذج الأولي» في الدالتين ` .unset` و` .omit`. يمكن للمهاجم استغلال طرق معقدة لإحداث حذف طرق من النماذج الأولية العالمية. تسمح هذه الثغرة بحذف الخصائص، لكنها لا تسمح بتعديل السلوك الأصلي لتلك الخصائص. التوصيات قم بالتحديث إلى الإصدار 4.17.23 من Lodash أو أحدث.