ذعر 10/10 Axios CVE: لماذا قمنا بتدقيق الضجيج وتصحيحه على أي حال
عندما ادعت العناوين الرئيسية أن عيبًا خطيرًا في Axios يمكن أن يسرق بيانات اعتماد AWS، لم يقم فريقنا بإجراء تحديث فحسب؛ بل بحثنا في منطق وقت التشغيل لمعرفة ما إذا كان التهديد حقيقيًا بالفعل.
إذا كنت قد قضيت أي وقت في عالم JavaScript، فقد لمست «axios». إنه الإعداد الافتراضي لطلبات HTTP في Node.js. من الشائع جدًا أننا نتعامل معها عادةً كجزء من اللغة نفسها. ولكن قبل بضعة أسابيع، دخلت الصناعة في انهيار جماعي. بدأت العناوين الرئيسية تصرخ بشأن ثغرة خطيرة 10/10 في Axios - CVE-2026-40175 - والتي من المفترض أنها سمحت للمهاجمين بتجاوز أمان AWS وسرقة بيانات اعتماد السحابة.
في Sweent، تتمثل خطوتنا الأولى عند انخفاض «10/10" في بدء تدقيق على مستوى المحفظة. سواء كنا ندير لوحات معلومات المؤسسة أو نقوم بتحديث مجموعات التطبيقات القديمة، فإننا لا ننتظر التنبيهات التلقائية لإخبارنا بوجود حريق. نبدأ في البحث عن الدخان بأنفسنا. ولكن أثناء بحثنا في هذه الثغرة الأمنية المحددة، وجدنا شيئًا فاتته العناوين المثيرة: بالنسبة لمعظم التطبيقات الحديثة، كان الاستغلال ميتًا عند وصوله.
تشريح الخوف
تم وصف الثغرة الأمنية بأنها «سلسلة أدوات». إذا لم تكن على دراية بهذا المصطلح، فكر فيه مثل آلة Rube Goldberg للقراصنة. تحتاج إلى عدة أشياء مختلفة لتحدث بشكل خاطئ بترتيب معين حتى يحدث الانفجار النهائي.
من الناحية النظرية، بدت السلسلة كما يلي:
يجد المهاجم طريقة للتسبب في تلوث النموذج الأولي في تطبيقك.
تلتقط Axios تلك القيم الملوثة عند دمج تكوينها الداخلي.
تتضمن هذه القيم أحرف CRLF (تغذية خط إرجاع النقل) التي تم إدخالها في العناوين.
تخدع هذه العناوين الخادم من أجل «طلب التهريب» أو تزوير الطلب من جانب الخادم (SSRF).
يستخدم المهاجم SSRF للوصول إلى خدمة البيانات الوصفية لمثيل AWS (IMDSv2) والابتعاد باستخدام بيانات اعتماد السحابة الخاصة بك.
على الورق، هذا سيناريو كابوس. إذا تمكن المهاجم من الوصول إلى
169.254.169.254من داخل شبكتك، فإنه يمتلك البنية التحتية الخاصة بك. ولكن هنا تكمن المشكلة: النظرية والإنتاج مكانان مختلفان للغاية.لماذا ربما أنقذك وقت التشغيل أثناء قيامنا بتدقيقنا، أدركنا أن البدائية الأساسية التي يعتمد عليها هذا الاستغلال - حقن رأس CRLF - هي شيء كان Node.js يحظره على مستوى وقت التشغيل لسنوات. لا ترسل Axios وحدات البايت عبر السلك نفسه؛ فهي تستخدم وحدة
httpالمدمجة في Node.js. عندما حاولنا إعادة إنتاج الاستغلال في بيئة قياسية، واصلنا الاصطدام بالحائط. على وجه التحديد، «خطأ النوع [ERR_INVALID_CHAR]». إذا حاولت تمرير قيمة رأس بحرف سطر جديد إلىhttp.request ()، فسيحدث خطأ Node.js قبل أن يغادر الطلب خادمك. لا يهم مدى «تلوث» تكوين Axios الخاص بك إذا رفض المحرك الأساسي القيادة. لقد تحققنا من ذلك، وتوجد نفس الحماية في Bun و Deno. إنها حالة كلاسيكية تتمثل في كون المكتبة ضعيفة تقنيًا ولكن البيئة آمنة. حتى أننا نظرنا إلى النتائج التي توصل إليها باحثون مثل راؤول فيجا ديل فالي. أكد عمله ما كنا نراه في مختبراتنا: في تطبيقات الإنتاج في العالم الحقيقي، يكاد يكون من المستحيل الوصول إلى هذه السلسلة لأن المترجم يوقفها تمامًا. فلماذا تصنيف 10/10؟ نظرًا لأن درجات CVE تفترض أسوأ بيئة ممكنة، وليس مجموعة Node 20.x المصححة جيدًا.
التدقيق المرسل
ما وراء الفحص الآلي قد تسأل لماذا أزعجنا التصحيح إذا كان وقت التشغيل يمنع الاستغلال. الجواب بسيط: نحن لا نراهن على الأمن على طبقة واحدة من الدفاع. يعد الاعتماد على Node.js لاكتشاف خطأ المكتبة عادة سيئة. قام فريقنا يدويًا بمراجعة ملفات «package-lock.json» و «yarn.lock» عبر كل مشروع نشط. لم نبحث فقط عن رقم إصدار «axios». نظرنا في كيفية تفاعل الكود فعليًا مع الشبكة. الأدوات الآلية مثل Dependabot رائعة، لكنها لا تفهم السياق. لا يعرفون ما إذا كنت قد كتبت محولًا مخصصًا قد يتجاوز حماية Node المضمنة.
لقد فحصنا المحولات المخصصة. إذا كان أحد التطبيقات يستخدم محول Axios مخصصًا يتجاوز عميل Node.js
http- ربما لكتابة الطلبات الأولية مباشرة إلى المقابس - تختفي حماية وقت التشغيل.بحثنا عن مخاطر التلوث النموذجية. إذا كان تطبيقك عرضة لتلوث النموذج الأولي، فستواجه مشكلات أكبر بكثير من مجرد خطأ Axios. قمنا بمراجعة كيفية تعاملنا مع
JSON.parseودمج الكائنات في جميع المجالات.لقد تحققنا من تكوينات AWS الخاصة بنا. حتى في حالة حدوث SSRF، فإننا نضمن أن مشاريعنا تستخدم IMDSv2 بحدود خطوات صارمة. هذا يجعل سرقة بيانات الاعتماد أكثر صعوبة حتى مع الحقن الناجح.
نظرنا في كيفية إنشاء العناوين. لقد بحثنا عن أي مكان قد تلمس فيه مدخلات المستخدم مفتاح العنوان أو القيمة دون التعقيم.
خلال فترة الـ 24 ساعة هذه، قمنا بنقل كل مشروع إلى Axios 1.15.0 أو أعلى. لقد رأينا «إرهاق التنبيه» يدمر فرق التطوير. فهم يتلقون مئات الإشعارات أسبوعيًا، معظمها يتعلق بتبعيات المطورين منخفضة المخاطر، ويبدأون في تجاهلها. نحن نتعامل مع الأمان كمهمة هندسية يدوية ذات أولوية عالية حتى لا تؤدي الضوضاء إلى حجب الإشارة.
الواقع الفوضوي لسلسلة التوريد
جاء هذا CVE في أعقاب حادثة Axios الأخرى الأكثر رعبًا: اختطاف حساب المشرف الذي أدى بالفعل إلى نشر حصان طروادة للوصول البعيد (RAT). كان ذلك هجومًا حقيقيًا على سلسلة التوريد. لم تكن «سلسلة أدوات» تتطلب أربع مصادفات لتعمل؛ بل كانت شفرة ضارة تعمل في خط أنابيب البناء الخاص بك.
تسلط المقارنة بين الاثنين الضوء على مشكلة رئيسية في الهندسة الحديثة. تميل الصناعة إلى المبالغة في الاستجابة للأخطاء النظرية على مستوى المكتبة بينما لا تستجيب بشكل كافٍ لتسويات الحساب. لقد أمضينا وقتًا في الحديث عن SSRF النظري أكثر مما فعلناه بشأن حقيقة أن المشرف الأساسي لم يتم تمكين 2FA على حساب npm الخاص به.
إن الحفاظ على دلتا بين الإصدار المثبت وأحدث إصدار مصحح صغيرًا قدر الإمكان هو الطريقة الوحيدة للبقاء عاقلًا. ولكن لا يمكنك تشغيل «npm update» بشكل أعمى. لقد رأينا تحديثات «ثانوية» تكسر عناوين الإنتاج أو تغير كيفية التعامل مع المهلات. هذا هو السبب في أن خطوط أنابيب CI/CD الخاصة بنا تتضمن اختبار الانحدار وبوابات الأمان. إذا نجح أحد التحديثات في كسر اختبار وحدة واحدة، فلن يتم المضي قدمًا.
متى لا يكون الخطأ «الحرج» حرجًا؟
استند تصنيف «10/10" لهذا CVE إلى السيناريو الأسوأ المطلق. إذا كنت تفترض أن مهاجمًا قد اخترق بالفعل النموذج الأولي لتطبيقك، وكنت تستخدم مكدس شبكة مخصص غريب، والبيانات الوصفية السحابية مفتوحة على مصراعيها - فنعم، إنها 10. ولكن بالنسبة للمطور العادي؟ إنه تذكير بالحفاظ على تبعياتك نظيفة.
لقد استولينا على المشاريع القديمة حيث لم يتم التطرق إلى «package.json» منذ عام 2022. هذه مسؤولية ضخمة. كل حزمة قديمة هي باب يُترك مفتوحًا. نحن نحرص على تثقيف شركائنا حول سبب أهمية عمليات التدقيق هذه. لا يتعلق الأمر بمطاردة كل عنوان، بل يتعلق بمعرفة الكود الذي يتم تشغيله بالضبط في بيئة الإنتاج الخاصة بك ولماذا.
ودعونا نكون صادقين: Axios يزداد انتفاخًا. إنها أداة رائعة، ولكنها تحمل الكثير من الوزن القديم لدعم المتصفحات وإصدارات Node القديمة. في بعض الأحيان لا يكون أفضل إصلاح للأمان هو التصحيح؛ إنه يتحول إلى واجهة برمجة تطبيقات «fetch» الأصلية إذا كنت تستخدم وقت تشغيل Node الحديث. يحتوي على ميزات أقل، ولكنه يحتوي أيضًا على سطح هجوم أصغر بكثير.
الوجبات الجاهزة لدينا
الأمان ليس ميزة «ضبطها ونسيانها». إنها عملية تحقق مستمرة. يسعدنا الإبلاغ عن تصحيح جميع أنظمتنا الداخلية والمنصات المُدارة والتحقق منها في غضون ساعات من الكشف، على الرغم من الاحتمال المنخفض للاستغلال الفعلي.
لم نقم بالتصحيح فقط لأن الأخبار أخبرتنا بذلك. قمنا بالتصحيح لأن المكتبة نفسها يجب ألا تسمح بالقيم غير الآمنة، حتى لو اكتشفها وقت التشغيل. يتعلق الأمر بالدفاع بعمق. إذا فشل خط الدفاع الأول (Axios)، فإن الخط الثاني (Node.js) يمسك به. في حالة فشل الثانية، يقوم الثالث (AWS IMDSv2) بحظر الجائزة. هذه هي الطريقة التي تبني بها أنظمة لا تنهار عندما تمر مكتبة واحدة بأسبوع سيء.
إذا كنت قلقًا بشأن شجرة التبعية الخاصة بك أو إذا لم تكن متأكدًا مما إذا كان فريقك الحالي يدرك هذه الفروق الدقيقة، فربما يجب عليك التحقق من «package-lock.json» الآن. هل تعتمد على الروبوت لإخبارك عندما تكون في خطر، أو هل لديك فريق يفهم بالفعل وقت التشغيل؟
أسئلة متكررة
تعكس درجة 10/10 أسوأ حالة على الإطلاق - بيئة حدث فيها تلوث النموذج الأولي بالفعل، ويتسرب حقن CRLF، ومحول الشبكة ليس وحدة Node http الخاصة بالمخزون، ويمكن الوصول إلى البيانات الوصفية السحابية من عملية التطبيق. من الناحية العملية، يطرح Node.js (وBun وDeno) TypeError [ERR_INVALID_CHAR] عندما يحتوي العنوان على سطر جديد، وبالتالي تتوقف السلسلة عند طبقة وقت التشغيل قبل وقت طويل من تعرض بيانات اعتماد AWS للخطر. يفترض تسجيل CVE أخطر بيئة معقولة، وليس بيئتك الفعلية.
نعم - الدفاع بعمق. لا ينبغي التسامح مع الأخطاء على مستوى المكتبة لمجرد أن الطبقة أدناه تنظف بعدها. يمكن أن يؤدي مُعيد بناء Axios المستقبلي، أو المحول المخصص الذي يتجاوز وحدة http، أو وقت تشغيل بديل إلى إزالة شبكة الأمان هذه بين عشية وضحاها. يعد التصحيح إلى 1.15.0+ رخيصًا؛ اعتمادًا على الرجوع الذي لم تكتبه يكون مكلفًا عندما يفشل.
ابدأ بملف القفل - package-lock.json أو yarn.lock - وتحقق من الإصدار الذي تم حله بالفعل، وليس فقط ما يعلنه package.json. ثم راجع كيفية استخدام المكتبة: محولات HTTP المخصصة، وإنشاء العنوان من مدخلات المستخدم، ومسارات دمج الكائنات التي يمكن أن تؤدي إلى تسرب تلوث النموذج الأولي، وما إذا كانت نقاط نهاية البيانات الوصفية السحابية (IMDSv2 مع حدود الخطوات الصارمة، في AWS) ستمنع سرقة بيانات الاعتماد حتى في حالة وصول SSRF. يرى Dependabot الإصدارات؛ يرى التدقيق الحقيقي سلوك وقت التشغيل.
من الناحية التشغيلية، نعم. تحتاج سلسلة الأدوات CVE إلى أربع مصادفات حتى تصل. حساب المشرف المخترق عبارة عن تعليمات برمجية ضارة يتم تنفيذها في خط أنابيب الإنشاء الخاص بك، ولا يلزم وجود سلسلة - هذا هو الهجوم الذي فقدنا النوم عليه بالفعل. الخلاصة الأوسع هي أن المصادقة الثنائية على npm وتوقيع الحزمة وتثبيت إصدارات التصحيح مهمة أكثر من مطاردة كل درجة من درجات CVE على مستوى المكتبة.
في Node الحديث (18+) وفي المتصفح، يعد هذا خيارًا حقيقيًا. يحتوي fetch على سطح API أصغر بكثير، ويتم شحنه مع وقت التشغيل، ويحمل وزنًا قديمًا أقل. المقايضات: لا توجد أجهزة اعتراضية افتراضية، وبيئة عمل مختلفة لمعالجة الأخطاء، ولا توجد مهلات مضمنة للطلب/الاستجابة بدون AbortController. بالنسبة للمشاريع الجديدة، غالبًا ما يكون الأمر يستحق الترحيل؛ بالنسبة لقواعد الرموز الثابتة الموجودة بالفعل على axios @1 .15.0+، فإن حماية وقت التشغيل بالإضافة إلى التحديثات المنضبطة جيدة.