Climba03003

Fastify incorrectly determines whether to compile a request schema based on JavaScript truthiness. According to JSON Schema Draft 7, a boolean `false` is a valid schema that rejects all instances. However, when `false` is assigned to a route's `body`, `querystring`, `params`, or `headers` schema to deny all input, the software treats it as a missing schema and fails to compile a validator. This allows an unauthenticated remote client to bypass validation and reach handlers intended to be unreachable, potentially leading to unauthorized state changes or the execution of disabled operations.

An issue exists where the object resolved by a successful Ajv async validator is treated as the value result protocol used by custom validator compilers. If a request that passes its route schema contains a property named `value` at the root, the software replaces the entire request body with the value of that property before the handler executes. This results in the handler receiving an object different from the one that satisfied the schema. An authenticated low-privilege caller can exploit this to replace the validated body with nested data, potentially triggering unauthorized operations, leading to unauthorized state changes and data disclosure.

توجد مشكلة في معالجة عمليات قراءة الرؤوس المُعادة التوجيه (forwarded-header) المستخدمة لاستخلاص قيم المضيف والبروتوكول واسم المضيف وعنوان IP وعناوين IP الخاصة بالطلب. عندما يتم تكوين الإعداد `trustProxy` بقيمة رقمية لعدد القفزات (hop-count)، يفشل النظام في التحقق من صحة عنوان الاتصال بشكل صحيح. وهذا يسمح للمهاجم الذي يمكنه الوصول إلى المصدر مباشرةً، متجاوزًا الوكيل الأمامي، بتزوير حقول الطلبات المعاد توجيهها. وقد يؤدي ذلك إلى حقن المضيف في عناوين URL التي يتم إنشاؤها، وتجاوز فرض بروتوكول HTTPS، وتجاوز أمان ملفات تعريف الارتباط ومصدر CSRF، بالإضافة إلى التوجيه المستند إلى المضيف وتسميم ذاكرة التخزين المؤقت.

توجد مشكلة في محلل بيانات النماذج متعددة الأجزاء (multipart form-data parser)، حيث يمكن أن تترك الدالة `saveRequestFiles()` ملفات مؤقتة على القرص إذا انقطع اتصال العميل أثناء انتقال المحلل بين الأجزاء المتعددة. ونظرًا لحدوث رفض المكرر خارج مسار التنظيف الخاص بكل ملف، لا تتم إزالة الملفات التي تم الانتهاء منها مسبقًا. ويمكن لعميل غير مصدق استغلال هذا السلوك للتسبب في استهلاك مستمر وخطي لمساحة القرص، مما يؤدي إلى رفض الخدمة.

يتم تعيين مفاتيح مجموعات تحديد معدل الاستخدام (rate-limit buckets) باستخدام سلسلة عنوان IP للعميل كما هي من `request.ip`. يمكن للعميل الذي يدعم IPv6 تجاوز حدود التحكم في معدل الاستخدام عن طريق تبديل العناوين ضمن نطاق عناوين واسع (مثل /64) أو باستخدام تمثيلات نصية مختلفة لنفس العنوان. وهذا يسمح للمهاجمين بتجاوز إجراءات الحماية على نقاط النهاية الحساسة مثل المصادقة، وإعادة تعيين كلمة المرور، وتسليم كلمة المرور لمرة واحدة (OTP)، أو استدعاءات واجهة برمجة التطبيقات (API) المكلفة، خاصةً عندما يكون التطبيق خلف وكيل (proxy) يعرض IPv6 إلى المصدر ويكون `trustProxy` ممكّنًا.

لا يتم التحقق من صحة مسارات وجهة WebSocket بشكل صحيح مقابل بادئة إعادة الكتابة المُعدة. تقوم الدالة `WebSocketProxy.findUpstream()` بحل الوجهات باستخدام مُنشئ عناوين URL الخاص بـ WHATWG، والذي يدمج أجزاء النقطة. وهذا يسمح لطلب ترقية مُصمم خصيصًا يحتوي على تسلسلات عبور المسار بتجاوز بادئة إعادة الكتابة والوصول إلى نقاط النهاية في الاتجاه الصاعد التي لا ينبغي الكشف عنها. يمكن استغلال هذه المشكلة عبر عملاء WebSocket غير المُعَدِّلين للمسارات، مثل عملاء HTTP الخام أو الوكلاء النهائيين الذين يعيدون توجيه هدف الطلب دون تعديل، حيث تقوم المتصفحات القياسية وحزمة `ws` بتوحيد المسارات قبل الإرسال.

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

يحدث تجاوز في البرمجيات الوسيطة عند تمكين الخيار `ignoreDuplicateSlashes` الذي تم إهماله. تفشل منطقية مطابقة مسار البرمجيات الوسيطة في مراعاة عملية توحيد علامات المائل المكررة التي يقوم بها جهاز التوجيه، مما يسمح للطلبات التي تحتوي على علامات مائل مكررة في البداية (على سبيل المثال، ’//admin/secret‘) بتجاوز عمليات التحقق من المصادقة والتفويض. تؤثر هذه المشكلة بشكل خاص على التطبيقات التي تستخدم نمط التكوين من المستوى الأعلى الذي تم إهماله `fastify({ ignoreDuplicateSlashes: true })` بدلاً من تكوين `routerOptions`.

لا يتم تسجيل برامج الوسيطة الموروثة مباشرةً في مثيلات محرك المكونات الإضافية التابعة. عندما يتم تسجيل برامج الوسيطة الخاصة بالمصادقة في نطاق أبوي ويتم تسجيل المكونات الإضافية التابعة باستخدام @fastify/middie، يفشل النطاق التابع في وراثة برامج الوسيطة الأبوية. يحدث هذا لأن مسارات البرامج الوسيطة تُعاد إضافة البادئة إليها بشكل غير صحيح عند نشرها إلى نطاقات المكونات الإضافية التابعة؛ فإذا تم تسجيل مكون إضافي تابع ببادئة تتداخل مع مسار برنامج وسيط في نطاق الأصل، يتم تعديل المسار ويفشل في مطابقة الطلبات الواردة. ونتيجة لذلك، يتم تخطي الضوابط الأمنية مثل المصادقة والتفويض والحد من المعدل لجميع المسارات المحددة ضمن نطاقات المكونات الإضافية التابعة والمتداخلة، مما يسمح للطلبات غير المصادق عليها بالوصول إلى تلك المسارات.

تحدث ثغرة «عبور المسار» (path traversal) عند تمكين عرض قائمة الدلائل عبر الخيار `list`. تقوم الدالة `dirList.path()` بحل مسارات الدلائل خارج الجذر الثابت المُعدّ باستخدام `path.join()` دون إجراء فحص للاحتواء. يمكن لمهاجم بعيد غير مصدق عليه الحصول على قوائم الدلائل لأي دلائل يمكن لعملية Node.js الوصول إليها، مما يؤدي إلى الكشف عن أسماء الدلائل والملفات، على الرغم من عدم الكشف عن محتويات الملفات.

يسمح عيب منطقي في مسار معالجة الرؤوس في إطار عمل Fastify الخاص بـ Node.js للمهاجمين عن بُعد غير المصادق عليهم بتجاوز الضوابط الأمنية. تحدث هذه المشكلة لأن الدالة `rewriteRequestHeaders()` تعالج رأس `Connection` الخاص بالعميل بعد أن يضيف الوكيل رؤوسه الخاصة. وهذا يسمح للمهاجم بإزالة الرؤوس التي أضافها الوكيل لأغراض التوجيه أو التحكم في الوصول أو الأمان بأثر رجعي، عن طريق إدراجها في قيمة رأس `Connection`. وقد يؤدي ذلك إلى تعديل غير مصرح به للمعلومات المحمية أو تجاوز آليات تحديد هوية الوكيل والتفويض.

توجد مشكلة تتمثل في فشل البرنامج في تطبيع عناوين URL قبل تمريرها إلى البرمجيات الوسيطة Express عند تمكين خيارات التطبيع في موجه Fastify. وهذا يسمح لمهاجم غير مصدق بتجاوز البرمجيات الوسيطة للمصادقة على نطاق المسار عن طريق التلاعب بمسار عنوان URL. وعلى وجه التحديد، يحدث التجاوز عبر الخطوط المائلة المكررة عند تمكين `ignoreDuplicateSlashes`، أو عبر فواصل الفاصلة المنقوطة عند تمكين `useSemicolonDelimiter`. في هذه السيناريوهات، يقوم موجه Fastify بتوحيد عنوان URL ليتطابق مع المسار، لكن عنوان URL الأصلي غير الموحد يتم تمريره إلى الوسيطة Express، مما يؤدي إلى فشل المطابقة وتخطيها.

يؤدي خطأ في معالجة المسارات في الدالة `onRegister()` إلى تكرار مسارات البرامج الوسيطة عند توريثها إلى المكونات الإضافية التابعة. وعندما يتم تسجيل مكون إضافي تابع ببادئة تتطابق مع مسار برنامج وسيط، تُضاف البادئة إلى المسار مرة ثانية، مما يمنعه من مطابقة الطلبات الواردة. ويؤدي ذلك إلى تجاوز كامل لضوابط أمان البرامج الوسيطة في Express، مثل المصادقة والتفويض والحد من معدل الطلبات، لجميع المسارات المحددة ضمن نطاقات المكونات الإضافية التابعة المتأثرة.

يوجد ثغرة تسمح بتجاوز المصادقة والتفويض بسبب عدم اتساق عملية فك تشفير عناوين URL بين جهاز التوجيه Fastify ومعالج الملفات الثابتة. حيث يعامل جهاز التوجيه فواصل المسارات المشفرة بنسبة المئوية (`%2F`) كأحرف حرفية، بينما يقوم معالج الملفات الثابتة بفك تشفيرها قبل تحديد موقع الملف في نظام الملفات. يسمح هذا التباين للمهاجمين بالالتفاف على البرامج الوسيطة القائمة على المسارات أو الحواجز المصممة لحماية مسارات محددة. على سبيل المثال، قد لا يتطابق الطلب الموجه إلى `/admin%2Fsecret.html` مع حاجز محدد لـ `/admin/*`، ولكنه سيُحل ويُعرض على أنه `/admin/secret.html` بواسطة معالج الملفات الثابتة.

التطبيقات التي تستخدم `schema.body.content` للتحقق من صحة نص الرسالة حسب نوع المحتوى معرضة لتجاوز عملية التحقق من الصحة. من خلال إضافة مسافة في بداية رأس Content-Type، يتم تحليل نص الرسالة بشكل صحيح، ولكن يتم تخطي عملية التحقق من صحة المخطط بالكامل.