Polyfill.io جعلت ملكية النطاق اختبارًا للمساءلة أمام المواقع النهائية

ملخص

• الموقع الذي حمّلcdn.polyfill.ioلم يكتف بالإشارة إلى مشروع مفتوح المصدر. بل سمح لخدمة عن بعد بأن تختار JavaScript وتعيدها لتنفيذها في سياق متصفح الموقع. لذا فإن كيان الثقة شمل النطاق والمشغل والتوجيه ومسار الاستجابة، وليس فقط الكود المصدري الذي يمكن فحصه في مكان آخر. [15][16][17]
• تغيرت السيطرة على نطاق Polyfill.io وحضور المشروع المرتبط به في فبراير 2024. تفاعلت كل من Fastly وCloudflare وإحدى قضايا مشروع FormatJS في ذلك الوقت، مما أظهر أن إعادة التقييم من المنبع كانت ممكنة قبل الإبلاغ العلني عن التسليم الضار في يونيو. لا ينبغي وصف النقل نفسه بأنه دليل على نية ضارة. [2][3][4]
• أفادت Sansec في 25 يونيو أن الخدمة كانت تعيد بشكل انتقائي JavaScript معدلة تعيد توجيه الزوار المؤهلين. قالت Cloudflare إن مؤشرات Page Shield تضمنت تطابقات تعود إلى 8 يونيو، بينما وصفت Akamai أخذ عينات من جانب الخادم متبوعًا بفحوصات من جانب العميل. تؤسس هذه الملاحظات حملة إعادة توجيه، وليس كل إجراء يمكن أن تؤديه JavaScript عن بعد نظريًا. [1][5][9]
• يشير تقدير Sansec لأكثر من 100,000 موقع إلى المواقع التي تضمن الخدمة أو تستخدمها. استشهدت Cloudflare بتقدير استخدام يقترب من أربعة بالمائة من المواقع. لا يمثل أي من الرقمين عددًا مثبتًا للمواقع التي خدمت الفرع الضار أو أعادت توجيه الزوار أو تعرضت لخسارة. [1][5]
• قيدت إعادة الكتابة التلقائية من Cloudflare وإيقاف Namecheap للنطاق مسار التسليم. لم يزيلا المراجع القديمة من كود المنبع، أو يحددا ما تلقاه كل زائر سابق، أو يكملان تحقيق كل مالك موقع. [5][6][10]
• توضح Fides وJellyfish وWordfence ثلاث مهام أدلة مختلفة: تحديد ما إذا كان المسار الشرطي قابلاً للوصول، وتتبع بائع متسلسل، والتحقق من الإزالة، وتجنب التعامل مع مرجع إلى نقطة النهاية كدليل على الاستغلال. [11][12][13][14][22]
• المساءلة هنا ليست استنتاجًا قانونيًا أو تأكيدًا للمساواة في اللوم. إنها تعني أن كل طرف يجب أن يكون مسؤولاً عن الضوابط التي يمكنه ممارستها فعليًا. احتفظ مالكو المواقع بالسيطرة على الضرورة والمخزون واختيار المزود والاستضافة الذاتية ومراقبة الملكية ومراقبة جانب المتصفح والتحقيق والإصلاح والاتصال.

وسم برمجي فوض السلطة، وليس فقط الراحة

بدا القرار التقني المركزي عاديًا. وضع موقع عنصرscriptفي صفحة ووجهه إلىcdn.polyfill.io. عندما زار زائر تلك الصفحة، طلب المتصفح JavaScript من الخدمة عن بعد. يمكن للخدمة فحص خصائص الطلب وتوفير polyfills مناسبة للمتصفح، مما يسمح للمتصفحات القديمة باستخدام ميزات ويب لم تنفذها أصلاً.

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

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

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

يمنح المتصفح JavaScript المحملة عن بعد تأثيرًا عمليًا واسعًا على الصفحة المضمنة. يعتمد المدى الدقيق على الصفحة وضوابط المتصفح، لكن الضعف الأساسي راسخ: تعمل وظائف الطرف الثالث ضمن سياق الويب للطرف الأول. يصف CWE-830 من MITRE هذه الفئة من التضمين على أنها نقل للثقة إلى كود من نطاق آخر، ويعامل OWASP JavaScript الطرف الثالث كمشكلة حوكمة لأنها يمكن أن تؤثر على البيانات وسلوك الصفحة. يطبق دليل GitHub CodeQL نفس المنطق على الوظائف المحملة من نطاق غير موثوق. [15][16][17]

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

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

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

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

نقل فبراير كان حدثًا لحوكمة البرمجيات

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

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

يُظهر إشعار Fastly بتاريخ 28 فبراير الأهمية الحوكمية. أعلنت عن نطاقات بديلة وأعطت المستخدمين خيارات تشمل الترحيل أو الاستضافة الذاتية أو إزالة الخدمة. لم تكن هذه الخيارات مجرد بدائل للعلامة التجارية. كل منها غير من سيتحكم في البايتات المسلمة للزوار. اختار الترحيل علاقة خدمة مختلفة. وضعت الاستضافة الذاتية التسليم تحت ضوابط النشر الخاصة بالموقع. ألغت الإزالة تبعية التوافق إذا لم تعد هناك حاجة إليها. [3]

تبعت Cloudflare في 29 فبراير ببديل مستضاف على cdnjs. ربط شرحها انتقال المزود بمخاطر سلسلة التوريد: اعتمدت المواقع على طرف آخر لصيانة وتأمين خدمة يمكنها تنفيذ كود في صفحاتها. بديل Cloudflare لم يجعل الاستضافة الخارجية خالية من المخاطر، لكنه أظهر أن مزودي البنية التحتية فهموا تغيير الملكية كأساس لقرار ثقة جديد. [2]

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

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

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

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

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

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

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

التسليم الانتقائي جعل الفحص العادي غير موثوق

في 25 يونيو، أبلغت Sansec أنcdn.polyfill.ioكان يسلم JavaScript معدلة عبر المواقع التي تضمنته. أعاد السلوك المرصود توجيه زوار مختارين عبر نطاقات مصممة لتشبه Google Analytics نحو وجهات احتيالية أو مراهنات. وصفت Sansec شروطًا تضمنت استهداف الجوال وفحوصات من جانب الخادم والعميل وسلوكًا زمنيًا وتجنبًا لبعض سياقات المسؤول أو التحليلات. [1]

يحتاج الفعل المرصود إلى اسم دقيق. كان حملة إعادة توجيه تم تسليمها عبر JavaScript معدلة. لا يدعم السجل ترقية هذه الملاحظة إلى سرقة بيانات اعتماد أو سرقة بيانات صفحة أو اختراق مضيف أو تنفيذ كود خارج المتصفح أو خسارة مالية قابلة للقياس. يمكن لنقطة نهاية سكربت مسيطر عليها عن بعد، من حيث المبدأ، إعادة JavaScript قادرة على نطاق أوسع بكثير من إجراءات المتصفح. يدعم أمن CNCF TAG وCWE-830 ونموذج تنفيذ المتصفح العام استنتاج القدرة. القدرة ليست دليلاً على أن كل إجراء محتمل قد حدث. [8][16]

قالت Cloudflare إن بيانات Page Shield أكدت المؤشرات وتضمنت تطابقات من 8 يونيو. هذا هو أقرب تطابق في مجموعة بيانات Cloudflare الموصوفة في سجل المصدر. إنه ليس دليلاً على أن كل النشاط الضار بدأ في ذلك التاريخ، أو أن نفس الفرع وصل إلى كل موقع بشكل مستمر منذ ذلك الحين، أو أنه لم يحدث تسليم سابق خارج نطاق رؤية Cloudflare. [5]

وصفت Akamai بشكل منفصل نمطًا من مرحلتين حيث يمكن للاختيار من جانب الخادم بناءً على رؤوس الطلب تحديد ما يتم إرساله، متبوعًا بفحوصات من جانب العميل قبل إعادة التوجيه. هذا التصميم يشرح لماذا يمكن أن يفوت الفحص العادي المشكلة. قد يتلقى مطور يطلب السكربت من متصفح سطح مكتب polyfill متوقع. قد يتلقى زائر جوّال برؤوس مختلفة أو موقع أو توقيت أو حالة صفحة فرعًا آخر أو تنشيطه. [9]

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

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

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

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

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

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

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

تقديرات الحجم لم تكن أعداد ضحايا

وصفت Sansec أكثر من 100,000 موقع على أنها تضمن الخدمة أو تستخدمها. استشهدت Cloudflare بتقديرات أن Polyfill.io ظهر على ما يقرب من أربعة بالمائة من المواقع. تنقل هذه الأرقام الاتساع المحتمل لخدمة معاد استخدامها على نطاق واسع. لا تشترك في نفس المقام، ولا يحدد أي منهما مجموعة كاملة من الاختراقات المؤكدة. [1][5]

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

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

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

يعزز علاج Wordfence لأنماط إضافات WordPress المتأثرة هذا الحد. حدد فهرسها استخدامات Polyfill.io لكنه حذر من افتراض أن كل نسخة إضافة سلمت محتوى ضارًا. يمكن للإضافات إدخال نقطة النهاية في العديد من المواقع، مما يجعل عمل المخزون عاجلاً، بينما لا يزال وجود الكود أقل من إثبات التنفيذ الضار في كل تثبيت. [14]

كرر الإبلاغ الحكومي القلق الخطير بشأن الحجم مع تركيز المشغلين على الإزالة والتحقيق. وصف CERT-AGID الاستحواذ والتسليم المعتمد على الرؤوس وأشار إلى رقم أكثر من 100,000. هذا التحذير المستقل يدعم الاهتمام الدفاعي الواسع، لكنه لا يحول المقام إلى زوار متأثرين مؤكدين. [21]

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

الاحتواء غير المسار؛ لم يكمل العلاج

تضمنت الاستجابة أطرافًا بأنواع مختلفة من السيطرة. أعادت Cloudflare كتابة مراجع Polyfill.io تلقائيًا على صفحات العملاء الوكيلة إلى مرآة مستضافة على Cloudflare. شرحت الشركة أن مجرد حظر النطاق الأصلي يمكن أن يكسر المواقع التي لا تزال تعتمد على الخدمة. حاولت إعادة الكتابة الحفاظ على التوافق المتوقع مع إزالة التبعية المباشرة على نقطة النهاية المتغيرة. [5]

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

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

ثم وضعت Namecheap نطاق Polyfill.io قيد التعليق، ووصفت الاستشارات الحكومية نقطة النهاية بأنها معلقة بحلول 27 يونيو. أزال الإجراء على مستوى النطاق مسار الخدمة المباشر لكنه قد يكسر أيضًا المواقع التي لا تزال تتوقع استجابة. كان التعليق رافعة احتواء مهمة يملكها المسجل. لم ينظف القوالب النهائية أو إعدادات الإضافات أو الصفحات المخبأة أو تكوينات مدير العلامات أو منتجات البائعين. [6][10]

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

نصحت CERT-FR ووحدة الأمن السيبراني في غرب أستراليا المشغلين بتحديد المراجع وإزالتها، والانتقال إلى بديل مسيطر عليه عند الحاجة، والنظر في ضوابط المتصفح مثل تكامل الموارد الفرعية وسياسة أمان المحتوى. ركز Semgrep بالمثل على الكشف على مستوى المستودع بدلاً من اعتبار تعليق النطاق كافيًا. [6][7][20]

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

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

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

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

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

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

أظهر Fides لماذا لا يزال الفرع الشرطي مهمًا

يسجل CVE-2024-38537 مشكلة تبعية في Fides. يمكن لمسارfides.jsذي الصلة تحميل Polyfill.io للمتصفحات القديمة. يحدد السجل الإصدارات المتأثرة ويقول إن الإصدار 2.39.1 أزال التعرض. كما يحافظ على حد مهم: لم يتم تحديد استغلال عبر Fides. [11][12]

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

الخطأ الثاني هو معاملة CVE كدليل على استغلال مستخدمي Fides. يمكن لسجل ثغرة أن يؤسس مسار تضمين غير آمن وإصدارات متأثرة دون إثبات أن الفرع الضار وصل إلى نشر معين. "يمكن أن يحمّل" و"لوحظ استغلاله" يجيبان على أسئلة مختلفة. حافظ سجل Fides صراحةً على هذا التمييز.

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

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

ناقشت نشرة SingCERT أيضًا حالة Fides التبعية واحتفظت بحد عدم ملاحظة الاستغلال. تكرار نشرة من CERT وطني يزيد من رؤية المشكلة؛ لا يحول الاحتمال إلى استغلال ملاحظ. [22]

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

أظهر Jellyfish كيفية تتبع تبعية متسلسلة

وثق إعلان Jellyfish مسارًا مختلفًا. اعتمدت خدمته على بائع يمكنه تحميل Polyfill.io تحت ظروف خاصة. حدد Jellyfish العلاقة المتسلسلة، واتصل بالبائع، وتحقق من الإزالة، وحدد نطاق مجموعة المتصفح التي قد وصلت إلى المسار. [13]

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

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

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

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

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

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

يمتد هذا النموذج إلى ما بعد هذه الحادثة. تحتاج المنظمة النهائية إلى طريق تصعيد لأي بائع قادر على تقديم كود قابل للتنفيذ. يجب أن يحدد العقد أو عملية الإعداد الفني من يمكنه الإجابة على أسئلة التبعية العاجلة، ومدى السرعة التي يمكن بها تعطيل سكربت طرف ثالث، وما هي السجلات المتاحة، وكيف يمكن للعميل التحقق من التغيير.

أظهرت إضافات WordPress لماذا يجب أن تبقى المراجع والاستغلال منفصلين

فهرست Wordfence استخدام Polyfill.io عبر أنماط إضافات WordPress المختلفة. هذا النوع من المخزون قيم لأن الإضافات يمكنها توزيع تبعية خارجية واحدة عبر العديد من المواقع التي تديرها بشكل مستقل. قرار مشرف صغير يمكن أن يصبح علاقة ثقة واسعة في المنبع دون أن يضيف كل مالك موقع نقطة النهاية بوعي. [14]

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

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

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

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

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

SRI و CSP كانا ضوابط، وليس إجابات سحرية

تكامل الموارد الفرعية، أو SRI، يسمح لمؤلف الصفحة بتوفير ملخص تشفير لمورد خارجي. يمكن للمتصفح الداعم جلب المورد ورفض تنفيذه إذا كانت البايتات المعادة لا تطابق الملخص المتوقع. تقدم مواصفات W3C ودليل تنفيذ MDN SRI كطريقة لمنع مضيف طرف ثالث مخترق من تغيير مورد تتوقع الصفحة المضمنة أن يظل ثابتًا بصمت. [18][19]

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

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

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

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

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

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

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

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

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

تساعد أدوات فحص الكود في العثور على مراجع معروفة. يؤكد دليل CodeQL الخاص بـ Polyfill على العناية بالملكية ومراجعة السجل والاستضافة الذاتية وقيود ضوابط السلامة للمحتوى الديناميكي. اقترح Semgrep عمليات بحث في المستودع وقواعد لتحديد استخدام Polyfill.io بعد الحادثة. [15][20]

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

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

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

يجب أن تتبع المساءلة الضوابط التي يملكها كل طرف

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

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

امتلكت Fastly وCloudflare قدرات البنية التحتية والاستبدال. إشعاراتهما في فبراير يمكن أن تحذر وتقدم بدائل. سمح موضع Cloudflare اللاحق بإعادة الكتابة التلقائية وتلميحات جانب العميل لحركة المرور المغطاة. كانت هذه الضوابط مهمة، لكنها لم تعطِ أيًا من المزودين معرفة كاملة بمصدر كل موقع نهائي أو تكوينه أو تأثير الزائر. [2][3][5]

امتلكت Namecheap رافعة احتواء على مستوى المسجل. وضع النطاق قيد التعليق قطع حل أو استخدام نقطة النهاية. هذا الإجراء قلل من التعرض المباشر مع احتمالية كسر المواقع المعتمدة. يمكن لسيطرة المسجل إيقاف مسار؛ لا يمكنها تصحيح التطبيقات أو تحديد التسليم التاريخي لكل موقع. [10]

امتلك باحثو الأمن والمستجيبون الحكوميون قدرات الكشف والتحليل والتحذير. نشرت Sansec مؤشرات وسلوكًا مرصودًا. أضافت Akamai وCloudflare وجهات نظر تلميحية. ترجمت CERT-FR وغرب أستراليا وCERT-AGID وSingCERT الحادثة إلى إرشادات مشغل لجماهيرها. يمكن لهذه الأطراف زيادة الرؤية والتوصية بالضوابط؛ لم يتمكنوا من نشر إصلاحات على كل موقع. [1][5][6][7][9][21][22]

سيطر مشرفو الإضافات والمكتبات والبائعين على الكود الذي يمكن أن يقدم التبعية بشكل متسلسل. تضمنت إجراءاتهم المسؤولة تحديد الإصدارات والظروف المتأثرة، وإزالة نقطة النهاية، وإصدار إصلاح، وتبليغ النطاق، والحفاظ على التمييز بين التعرض المحتمل والاستغلال الملاحظ. تظهر سجلات Fides وإضافات WordPress لماذا الإصدار وأدلة قابلية الوصول مهمة. [11][12][14]

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

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

يمكن تنظيم خارطة واجبات مفيدة حول ستة أسئلة.

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

ثانيًا، من يمكنه اكتشاف الثقة المتغيرة؟ يمكن لمراقبي النطاق والبنية التحتية ملاحظة تغييرات الملكية وDNS والتوجيه. يمكن لمشرفي المشاريع تتبع سيطرة الحساب والتوثيق. يمكن لأصحاب المواقع الاشتراك في الإشعارات ذات الصلة ومراجعة التبعيات عالية السلطة عندما يتغير مشغلها.

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

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

خامسًا، من يمكنه التحقيق في الأثر؟ يملك كل مالك موقع بنية صفحته الخاصة وسجلات الزوار وشكاواه وتاريخ النشر. يملك البائعون معلومات حول الظروف المتسلسلة. يملك مزودو البنية التحتية تلميحات حركة مرور واستجابة محددة. تطلب التحقيق تعاونًا دون التظاهر بأن مجموعة بيانات أحد الأطراف تمثل جميع الزوار.

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

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

ما يجب أن يكون الموقع النهائي قادرًا على إثباته

يمكن التعبير عن استجابة نهائية موثوقة كسلسلة أدلة بدلاً من ضمان عام.

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

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

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

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

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

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

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

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

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

نقل النطاق يمكن أن يكون تغييرًا برمجيًا

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

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

الحادثة لا تبرر وصف أكثر من 100,000 موقع كضحايا مؤكدين. لا تثبت أن كل مرجع خدم محتوى ضارًا، أو أن كل زائر تعرض، أو أن كل منتج نهائي تم استغلاله. كما لا تبرر وصف الكود المصدري الأصلي بأنه خبيث عالميًا أو معاملة نسخة مستضافة ذاتيًا على أنها مماثلة للعلاقة المخترقة المستضافة.

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

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

بالنسبة للمالكين النهائيين، المعيار الدائم هو مباشر: اعرف كل طرف خارجي يمكنه اختيار كود لزوارك؛ راقب الحقائق التي جعلت ذلك الطرف جديرًا بالثقة؛ أزل السلطة التي لم تعد تخدم وظيفة ضرورية؛ واحتفظ بأدلة كافية للتمييز بين التعرض والتسليم والضرر.

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

المصادر

1. https://sansec.io/research/polyfill-supply-chain-attack
2. https://blog.cloudflare.com/polyfill-io-now-available-on-cdnjs-reduce-your-supply-chain-risk/
3. https://community.fastly.com/t/new-options-for-polyfill-io-users/2540
4. https://github.com/formatjs/formatjs/issues/4363
5. https://blog.cloudflare.com/automatically-replacing-polyfill-io-links-with-cloudflares-mirror-for-a-safer-internet/
6. https://cert.ssi.gouv.fr/actualite/CERTFR-2024-ACT-030/
7. https://soc.cyber.wa.gov.au/advisories/20240626004-JavaScript-Polyfill-Supply-Chain-Attack/
8. https://tag-security.cncf.io/community/catalog/compromises/2024/polyfill/
9. https://www.akamai.com/blog/security/polyfill-supply-chain-attack-what-to-know
10. https://socket.dev/blog/namecheap-takes-down-polyfill-io-service-following-supply-chain-attack
11. https://www.cve.org/CVERecord?id=CVE-2024-38537
12. https://nvd.nist.gov/vuln/detail/cve-2024-38537
13. https://jellyfish.co/library/jellyfish-security-advisory-june-27-2024/
14. https://www.wordfence.com/threat-intel/vulnerabilities/detail/various-plugins-various-version-use-of-polyfillio
15. https://codeql.github.com/codeql-query-help/javascript/js-functionality-from-untrusted-domain/
16. https://cwe.mitre.org/data/definitions/830.html
17. https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html
18. https://www.w3.org/TR/SRI/
19. https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/SRI
20. https://semgrep.dev/blog/2024/protect-your-code-from-the-polyfill-supply-chain-attack/
21. https://cert-agid.gov.it/news/scoperto-un-grave-attacco-alla-supply-chain-del-servizio-polyfill-io-piu-di-100-000-i-siti-coinvolti/
22. https://isomer-user-content.by.gov.sg/36/8bee5efc-3166-44a1-89ae-0f0b095ecb17/03-July-2024.pdf