ملكية نطاق 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 الطرف الثالث كمشكلة حوكمة لأنها يمكن أن تؤثر على البيانات وسلوك الصفحة. يطبق دليل CodeQL من GitHub نفس المنطق على الوظائف المحملة من نطاق غير موثوق. [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 Security و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، فإن البرنامج النصي عن بعد الأقل خطورة هو الذي لا تطلبه الصفحة. لهذا السبب تنتمي مراجعة دورة الحياة جنبًا إلى جنب مع ضوابط الأمان. قرارات التوافق المتخذة قبل سنوات لا ينبغي أن تصبح منح سلطة دائمة.

يمكن لـ sandboxing تقليل بعض تأثير الطرف الثالث عندما يمكن تنفيذ الوظيفة في إطار مقيد أو سياق معزول. ليس كل برنامج نصي يمكن نقله إلى هناك دون تغيير المنتج. 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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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