Sapphi-Red

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

تسمح هذه الثغرة الأمنية للمهاجم بسرقة شفرة المصدر الخاصة بالمستخدمين عند دخولهم إلى موقع ويب ضار. ويحدث ذلك لأن طلب تشغيل سكريبت تقليدي عبر علامة script لا يخضع لسياسة «نفس المصدر» (same-origin policy)، مما يسمح للمهاجم بحقن سكريبت ضار وتنفيذه. يحتاج المهاجم إلى معرفة المنفذ ومسار البرنامج النصي لنقطة الدخول. ومن خلال الجمع بين ذلك وتلوث النموذج الأولي، يمكن للمهاجم الحصول على مرجع إلى متغيرات وقت التشغيل الخاصة بـ webpack. ويتيح استخدام `Function::toString` في القيم الموجودة في ` webpack modules ` للمهاجم الحصول على شفرة المصدر.

تسمح هذه الثغرة لمهاجم بالحصول على شفرة المصدر من خلال طريقة مشابهة لتلك المستخدمة لاستغلال ثغرة أمنية تم الإبلاغ عنها سابقًا. ويحدث ذلك لأن webpack-dev-server يسمح دائمًا برؤوس `Origin` الخاصة بعناوين IP، مما يتيح للمواقع التي يتم تقديمها عبر عناوين IP الاتصال عبر WebSocket. ويتم التحقق من رأس `Origin` لمنع اختطاف WebSocket بين المواقع (Cross-site WebSocket hijacking).

تشبه هذه المشكلة ثغرة أمنية معروفة سابقًا. عند تشغيل خادم Next.js محليًّا، يكون خادم WebSocket عرضة لهجمات اختطاف WebSocket بين المواقع (CSWSH). إذا زار مستخدم رابطًا ضارًا أثناء تشغيل خادم Next.js للتطوير، فيمكن للمهاجم الوصول إلى شفرة المصدر لمكونات العميل. ويؤثر ذلك على التطبيقات التي تستخدم App Router، الذي كان تجريبيًا في الإصدارات من 13.0.0 إلى 13.3.x. تتيح هذه الثغرة الأمنية للمهاجم التجسس على أنشطة التطوير وسرقة شفرة المصدر.

اسم البرنامج المعرض للثغرة والإصدارات المتأثرة: إصدارات Vitest الأقدم من 2.1.9 إصدارات Vitest الأقدم من 3.0.4 الوصف: يستجيب المُعالج ` screenshot-error` في خادم HTTP الخاص بوضع المتصفح لأي ملف موجود في نظام الملفات. إذا كان الخادم مكشوفًا على الشبكة عبر `browser.api.host: true`، فيمكن للمهاجم إرسال طلب إلى هذا المُعالج عن بُعد للحصول على محتوى ملفات عشوائية. تتيح هذه الثغرة للمهاجمين قراءة ملفات عشوائية على النظام. التوصيات: بالنسبة للإصدارات الأقدم من 2.1.9، قم بالتحديث إلى الإصدار 2.1.9 أو أحدث. بالنسبة للإصدارات الأقدم من 3.0.4، قم بالتحديث إلى الإصدار 3.0.4 أو أحدث. كحل بديل مؤقت، ضع في اعتبارك تعطيل الإعداد `browser.api.host: true` لمنع تعرض خادم وضع المتصفح للشبكة. قم بتقييد الوصول إلى المعالج ` screenshot-error` لتقليل مخاطر الاستغلال. تجنب استخدام المعلمة `file` في المعالج ` screenshot-error` حتى يتم حل المشكلة.

Vitest، وهو إطار عمل للاختبار يعتمد على Vite، معرض لتنفيذ تعليمات برمجية عشوائية عن بُعد عند الوصول إليه عبر موقع ويب ضار أثناء استماع خادم واجهة برمجة التطبيقات (API) الخاص بـ Vitest. ويرجع ذلك إلى ثغرة أمنية تُعرف باسم «اختطاف WebSocket بين المواقع» (CSWSH). عندما تكون الخيار `api` ممكّنًا (وهو ما تفعله واجهة المستخدم لـ Vitest بشكل افتراضي)، يقوم Vitest بتشغيل خادم WebSocket لا يتحقق من رأس Origin ولا يطبق أي آلية للتوثيق. يتضمن هذا الخادم واجهتي برمجة التطبيقات `saveTestFile` و`rerun`. يمكن للمهاجم استغلال هذه الثغرة عن طريق حقن كود في ملف اختبار باستخدام واجهة برمجة التطبيقات `saveTestFile`، ثم تنفيذ هذا الكود باستدعاء واجهة برمجة التطبيقات `rerun`، مما قد يؤدي إلى تنفيذ كود عن بُعد للمستخدمين الذين يستخدمون خادم واجهة برمجة التطبيقات الخاص بـ Vitest.

يسمح إصلاح غير مكتمل في أدوات إنشاء webpack و rspack بسرقة شفرة المصدر أثناء التطوير. يحدث هذا إذا كان خادم التطوير مرتبطًا بعنوان غير loopback (على سبيل المثال، باستخدام `nuxt dev --host`) وقام مطور بزيارة موقع ويب ضار على نفس الشبكة. تنبع المشكلة من الاعتماد على رؤوس `Sec-Fetch-Mode` و`Sec-Fetch-Site`، التي لا ترسلها المتصفحات إلا للمصادر التي يُحتمل أن تكون موثوقة، مما يسمح بتجاوز الفحص بالنسبة للمصادر غير الموثوقة.

يمكن سرقة شفرة المصدر أثناء التطوير عند استخدام أداة البناء webpack أو rspack، وإذا قام الضحية بفتح موقع ويب ضار. نظرًا لأن طلب سكريبت تقليدي عبر علامة script لا يخضع لسياسة «نفس المصدر» (same-origin policy)، يمكن للمهاجم حقن سكريبت ضار في موقعك وتنفيذه. وعند استخدام `Function::toString` على القيم الموجودة في `window.webpackChunknuxt app`، يمكن للمهاجم الحصول على شفرة المصدر.