Ulisesgascon

عندما يقوم الوكيل (Agent) بتركيب معترضات إعادة التوجيه والتخزين المؤقت المشترك، يمكن التحقق من صحة استجابة مخزنة مؤقتًا يتم إعادة التحقق منها باستخدام طلب شرطي بشكل خاطئ من خلال استجابة 304 Not Modified من مصدر مختلف. يحدث هذا لأن معالج إعادة التوجيه يقوم بإزالة ترويسات الاعتماد المرتبطة بالمصدر ولكن يفشل في إزالة أدوات التحقق `If-None-Match` أو `If-Modified-Since` التي أنشأها التخزين المؤقت. نتيجة لذلك، يتلقى وجهة إعادة التوجيه أداة التحقق الخاصة بالمصدر الأصلي، ويعتبر النظام استجابة 304 بمثابة إعادة تحقق ناجحة. قد يؤدي ذلك إلى قيام التخزين المؤقت المشترك بتقديم استجابة مصادق عليها، مثل تلك المحمية بترويسة `Authorization` ، إلى مستخدم غير مصادق عليه.

عند استخدام معترض إعادة التوجيه وذاكرة تخزين مؤقت مشتركة للاستجابة معاً، يتم تخزين الاستجابة النهائية لطلب مصادق عليه تم إعادة توجيهه إلى هدف من نفس الأصل تحت مفتاح التخزين المؤقت للطلب الأصلي. وبما أن هذا المفتاح يحذف بيانات الاعتماد ولا يحتوي على ترويسة Vary، فقد يتم تقديم جسم الاستجابة الخاص بالمستخدم الأول لمستخدم مجهول أو مستخدم مختلف لاحقاً، مما يؤدي إلى كشف الاستجابات الخاصة المخزنة مؤقتاً بين المستخدمين.

توجد مشكلة في عميل HTTP حيث يؤدي استخدام معترض التخزين المؤقت (cache interceptor) مع معالج تالٍ (downstream handler) يقوم برمي استثناء أثناء معالجة الاستجابة إلى تسرب استثناء غير متزامن كاستثناء غير ملتقط أو رفض وعد غير معالج، مما يؤدي إلى إنهاء عملية Node.js. يمكن لخادم HTTP خبيث أو مخترق أن يتسبب في تعطل العميل عن طريق تقديم استجابة قابلة للتخزين المؤقت تؤدي إلى رمي استثناء عند إعادة التشغيل، بما في ذلك أثناء إعادة التحقق 304 من إدخال قديم، مما يؤثر على توفر الخدمة فقط. من الأمثلة على المعالجات التي قد تسبب ذلك تجاوز معترض التفريغ (dump interceptor) لقيمة `maxSize` الخاصة به، أو رفض معترض فك الضغط لأكثر من خمس قيم من Content-Encoding.

تقوم دالة `fetch` بالتحقق من بيانات سلامة الموارد الفرعية (SRI) بشكل غير صحيح عن طريق تقسيم سلسلة السلامة باستخدام مسافة واحدة فقط. وبما أن قواعد SRI تسمح بأي مسافة بيضاء ASCII، بما في ذلك علامة الجدولة الأفقية، فإن أي ملخص (digest) يسبقه مثل هذا الفراغ يتم اعتباره رمزًا غير معروف ويتم تجاهله. وإذا لم تبق أي خوارزميات معروفة، يتم التعامل مع قائمة السلامة على أنها فارغة، مما يسمح للخادم بإرسال محتوى استجابة يختلف عن الملخص المحدد دون إثارة خطأ في السلامة. يتيح ذلك للمهاجم الذي يتحكم في محتوى الاستجابة إرسال بيانات ضارة إلى التطبيق الذي يستخدم قيم SRI محاطة بمسافات بيضاء.

عندما يقوم وكيل بدون أصل (originless Agent) بتركيب معترضات إعادة التوجيه والتخزين المؤقت المشترك، يحدد النظام ما إذا كان سيتم تخزين الاستجابة النهائية تحت مفتاح الطلب الأصلي من خلال فحص قفزة إعادة التوجيه النهائية فقط. يسمح هذا بإعادة توجيه تمر عبر أصل غير موثوق وتعود إلى أصل موثوق ليتم تخزينها مؤقتًا تحت المفتاح الموثوق. وبناءً على ذلك، قد يتم إسقاط ترويسة `Vary` الخاصة بقفزة وسيطة، مما قد يؤدي إلى تقديم استجابات تختلف بناءً على `Authorization` أو `Cookie` لمستخدمين مختلفين. بالإضافة إلى ذلك، قد يتم تجاهل حالة `no-cache` أو `default-uncacheable` لقفزة وسيطة، مما يسمح بمعاملة إعادة توجيه غير قابلة للتخزين كإدخال قابل للتخزين المؤقت. يمكن للمهاجم الذي يتحكم في هدف إعادة التوجيه من عنوان URL موثوق أن يسمم الإدخال المخزن مؤقتًا أو يتسبب في تقديم استجابة خاصة بمستخدم معين لطلبات لاحقة.

يفشل اعتراض إعادة التوجيه في إزالة الرؤوس الحساسة—بما في ذلك `Authorization` و `Cookie` و `Proxy-Authorization` و `Host`—عندما يتم إعادة توجيه الطلب إلى أصل مختلف إذا تم تقديم رؤوس الطلب كمصفوفة من توابل الاسم والقيمة. في هذا السيناريو، يسيء معالج إعادة التوجيه تفسير التوابل على أنها قائمة مسطحة، مما يمنع تطابق أسماء الرؤوس ويسمح ببقاء الرؤوس الحساسة. إذا تم تركيب معترض لتطبيع الرؤوس، مثل cache أو deduplicate، خارج معترض إعادة التوجيه، يتم حينئذٍ تسلسل هذه الرؤوس المحتفظ بها في طلب الأصل المتقاطع، مما قد يؤدي إلى كشف بيانات اعتماد الأصل لجهة وجهة إعادة توجيه غير ذات صلة.

يقوم هذا المكون الإضافي بتوجيه الطلبات إلى خادم HTTP خارجي (upstream). وهو يفشل في التحقق من صحة مسارات الوكيل بشكل صحيح لأنه يتحقق فقط من مقاطع النقطة التي تحتوي على شرطة مائلة أمامية (forward-slash). يقوم محلل URL WHATWG بتحويل الشرطات المائلة الخلفية (backslashes) وأشكالها المشفرة بنسبة مئوية إلى شرطات مائلة أمامية في مخططات http و https و ws و wss. وبناءً على ذلك، يمكن للمسار الذي يستخدم مقاطع نقطة بشرطة مائلة خلفية تجاوز فحوصات التخطي، مما يسمح للطلبات غير المصرح بها بالهروب من البادئات المحددة والوصول إلى نقاط نهاية خارجية غير مقصودة. يؤدي ذلك إلى تأثير على السرية وتأثير محدود على السلامة.

قد يتوقف التطبيق الذي يستخدم إضافة CORS لإطار عمل Fastify عن العمل أثناء طلب preflight CORS إذا تم تسجيل الإضافة باستخدام خيار hook `onSend` غير الافتراضي. عند استلام طلب OPTIONS يحتوي على ترويسات Origin و Access-Control-Request-Method، تقوم الإضافة باستدعاء `reply.send()` من داخل hook `onSend` مما يؤدي إلى كتابة ترويسات الاستجابة مرتين. يتسبب ذلك في حدوث خطأ ERR HTTP HEADERS SENT غير معالج يمكن أن يؤدي إلى إنهاء عملية Node.js في حال عدم وجود معالج على مستوى العملية. يمكن لعميل عن بُعد غير مصرح له تحفيز هذه الحالة بطلب preflight واحد، مما يؤثر على توفر الخدمة.

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

عند تكوين المكون الإضافي بخيار ملف تعريف الارتباط الموقع، فإنه يفشل في إيقاف المعالجة عندما يبلغ فحص التوقيع عن قيمة غير صالحة. بدلاً من ذلك، يقوم بتمرير قيمة ملف تعريف الارتباط الأصلية إلى فك ترميز الجلسة، مما يسمح بفك تشفير جلسة ذات توقيع غير صالح. يحدث هذا إذا كان التطبيق يستخدم سر توقيع ملف تعريف الارتباط بشكل مستقل عن مفتاح تشفير الجلسة ويقوم بتدوير سر التوقيع فقط. يمكن للمهاجم الذي يمتلك ملف تعريف ارتباط جلسة مشفرًا وغير منتهي الصلاحية إزالة التوقيع القديم للاستمرار في استخدام الجلسة. لا يمكن للمهاجم تزوير بيانات الجلسة أو تمديد انتهاء الصلاحية أو تجاوز تدوير مفتاح التشفير.

تقوم عملية التحقق من الوجهة بتطبيع الشرطات المائلة الخلفية الحرفية قبل فك ترميز النسبة المئوية لمسار الطلب. يسمح هذا للمسار الذي يحتوي على شرطات مائلة خلفية مرمزة وأجزاء نقطية بتجاوز فحص الأجزاء النقطية. إذا كان الخادم العلوي (upstream) يتعامل مع الشرطة المائلة الخلفية كفاصل للمسار، فقد يخرج الطلب الموجه عن بادئة الوكيل (proxy prefix) المكونة ويصل إلى موقع مجاور في الخادم العلوي. يمكن لمهاجم عن بعد غير مصرح له استغلال ذلك لاسترداد موارد من الخادم العلوي خارج البادئة المحددة، مما يؤثر على السرية.

عندما يستخدم التطبيق بادئة مُعلمة (parameterized prefix) وخيارات `rewritePrefix` لتثبيت العملاء على مسار upstream ثابت، يقوم المكون الإضافي باستبدال مُعلمات المسار التي تم فك ترميز URL الخاص بها في `rewritePrefix` دون إعادة ترميزها. يمكن للمهاجم عن بُعد غير المصرح له تقديم قيمة مُعلمة ترميز فاصل مسار مع محدد جزء (fragment) أو محدد استعلام (query delimiter). يتم فك ترميز ذلك إلى فواصل ومحددات حقيقية تؤدي إلى حقن مقاطع مسار upstream إضافية وإزالة اللاحقة الإلزامية التي كان من المفترض أن يفرضها `rewritePrefix`. يسمح هذا للمهاجم بالوصول إلى مواقع upstream خارج البادئة المقصودة، مما يؤدي إلى تجاوز قيود المسار، وهو ما قد يتسبب في تزوير طلبات الخادم (SSRF) أو تجاوز التفويض في الخدمة الموكلة (proxied service).

توجد مشكلة في حجب الخدمة عندما يتم تكوين الخادم بـ `handlerTimeout` غير صفري وتكون المسار (route) يعيد استجابة تدفقية (streaming response). إذا ظل تدفق الطلب مفتوحًا بعد انتهاء المهلة بعد إرسال الرؤوس، يحاول الخادم إرسال استجابة خطأ جديدة. يؤدي ذلك إلى إثارة استثناء `ERR HTTP HEADERS SENT` غير معالج، مما يؤدي إلى إنهاء عملية Node.js ومقاطعة جميع الطلبات الأخرى النشطة. يمكن لعميل عن بُعد غير مصرح له تحفيز ذلك عن طريق إرسال طلب واحد إلى نقطة نهاية تدفقية متأثرة.

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

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

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

عندما يتم تكوين إدخال وكيل (proxy) لتوجيه WebSockets، يقوم الخادم بتوجيه طلبات ترقية WebSocket غير المتعلقة بـ HMR (Hot Module Replacement) إلى هدف الوكيل دون التحقق من ترويسات Host أو Origin. يؤدي هذا إلى تجاوز حماية allowedHosts. وبناءً على ذلك، يمكن لصفحة ويب خبيثة يزورها المطور فتح اتصال WebSocket عبر النطاقات من خلال خادم التطوير للقراءة والكتابة في الخلفية الموجهة عبر الوكيل، حتى عندما يكون الخادم مرتبطًا بعنوان loopback.

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

يقوم نقطة النهاية 'open-editor' غير المصادق عليها بالتحقق من ترويسة Host باستخدام تعبير نمطي مصمم لمخططات أصل المتصفح. يمكن لقيمة Host التي تبدأ بـ `file:` أو مخطط توسعة أن تتجاوز فحوصات اسم المضيف و `allowedHosts`. يمكن لند شبكي إرسال طلب بـ Host مشوه يجتاز التحقق، مما يؤدي إلى فشل بناء عنوان URL لنقطة النهاية. في وضع عدم الإنتاج الافتراضي، يعيد الخادم استجابة HTTP 500 تحتوي على تتبع المكدس الكامل للاستثناء، مما يكشف عن مسارات نظام الملفات المطلقة، ومواقع الوحدات المثبتة، وأرقام أسطر المصدر الداخلية.

تقوم الدالتان `normalize()` و `serialize()` بتطبيق إزالة قطاع النقطة (dot-segment removal) وفقًا لمعيار RFC 3986 بشكل خاطئ على مسار مرجع المسار النسبي. تم تحديد هذه الخوارزمية فقط لمسار الهدف المدمج أثناء عملية الحل. ونتيجة لذلك، قد يتم إسقاط قطاع دليل أب رائد، مما يؤدي إلى تحول المرجع النسبي للمستند إلى مرجع نسبي للجذر. يمكن للتطبيقات التي تقوم بتطبيع المراجع النسبية المقدمة من المستخدم قبل حلها، أو تستخدمها كمفاتيح للتخزين المؤقت أو إلغاء التكرار أو التفويض، أن تسمح للمرجع بالخروج من دليله المخصص والإشارة إلى مورد مختلف.