<script src= "cdn/lib.js" integrity= "sha384-oqV..."SHA-384mismatch → refuse to load

سلامة الموارد الفرعية

10 دقيقة قراءةتكنولوجيا الويب

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

يتم توفير نص المقالة الكامل باللغة الإنجليزية أدناه.

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

SRI الموحد لـ W3C في عام 2016. استغرق التبني سنوات وهو الآن واسع النطاق - تدعمه المواقع الرئيسية وشبكات CDN على نطاق واسع.

التهديد الذي يعالجه SRI

بدون SRI، صفحة تحميل

تحمل سمة التكامل الخوارزمية (sha384 هنا؛ كما يتم دعم sha256 وsha512 أيضًا) والتجزئة المشفرة بالأساس 64. السمة crossorigin مطلوبة حتى يتمكن المتصفح من استخدام CORS لجلب المورد والتحقق منه.

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

ما يحميه SRI وما لا يحميه

SRI من التعديلات غير المتوقعة للمورد المحدد. لا يؤدي ذلك إلى ما يلي:

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

تثبيت الإصدار المقايضة

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

  • التثبيت على إصدار محدد باستخدام SRI لاكتشاف التلاعب
  • استخدام مصادر التحديث التلقائي بدون SRI والثقة في المورد

بالنسبة للمواقع عالية القيمة، يعد تثبيت الإصدار باستخدام SRI هو الإعداد الافتراضي الأكثر أمانًا. بالنسبة للمواقع التي يكون فيها التصحيح الأمني ​​التلقائي للمكتبة أكثر أهمية من اكتشاف التلاعب (نادرًا)، فإن المقايضة تسير في الاتجاه الآخر.

SRI وCSP معًا

SRI يقترن بشكل طبيعي مع سياسة أمان المحتوى. يمكن لـ CSP تحديد require-sri-for script style، مما يجعل المتصفح يرفض تحميل أي برنامج نصي أو ورقة أنماط بدون سمة تكامل. وهذا يفرض استخدام SRI على مستوى السياسة، مما يمنع الإغفال العرضي.

الجمع - CSP + SRI + قيود الأصل الصحيحة - هو الوصفة الحديثة لصفحات الويب المحصنة.

الواقع التشغيلي

SRI مدعوم جيدًا من قبل المتصفحات (Chrome، Firefox، Safari، Edge) ومن خلال شبكات CDN الرئيسية (jsDelivr، cdnjs، unpkg كلها توفر تجزئات SRI للمكتبات المستضافة). العائق السائد أمام التبني هو التعقيد التشغيلي:

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

تتضمن أطر العمل الرئيسية (webpack، Vite، package، esbuild) مكونات SRI الإضافية للتعامل مع تجزئة وقت البناء. بالنسبة للتطبيقات النموذجية، تكون هذه مهمة إعداد لمرة واحدة.

SRI في عام 2026

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

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

الأسئلة المتداولة

لماذا يعد SRI ضروريًا إذا كنت أستخدم HTTPS بالفعل؟
يحمي HTTPS البرنامج النصي أثناء النقل بين CDN والمتصفح. إنه لا يحمي من اختراق CDN نفسه. إن خدمة CDN التي تقدم لك نصًا برمجيًا ضارًا عبر اتصال TLS صالح تمامًا هو بالضبط ما يدافع SRI ضده.
هل يجب علي تحديد SRI في كل برنامج نصي؟
بالنسبة للنصوص البرمجية الخارجية، نعم، حيث تكمن القيمة. لا تستفيد البرامج النصية المستضافة ذاتيًا على أصلك من SRI بنفس القدر (إذا تم اختراق أصلك، فستكون الصفحة نفسها كذلك). تطبق معظم الإعدادات الحديثة SRI على الموارد المستضافة على CDN.
ماذا لو كانت مكتبتي يتم تحديثها بشكل متكرر؟
القفل على إصدار محدد وتحديث الإصدار + التجزئة معًا. التحديث التلقائي إلى "الأحدث" يتعارض مع SRI. بالنسبة لمعظم مواقع الإنتاج، تعد الإصدارات المثبتة هي الخيار الصحيح على أي حال - فقد تسببت التحديثات التلقائية للتبعيات في حوادث إنتاج حقيقية.
هل يستطيع المهاجمون تجاوز SRI؟
ليس على مستوى البروتوكول، فالحسابات قوية. تأتي التجاوزات العملية من التكوين الخاطئ: فقدان سمة crossorigin (يتسبب في فشل الفتح في بعض السيناريوهات)، أو سيطرة المهاجم على الصفحة نفسها (وفي هذه الحالة لا يحتاجون إلى تجاوز SRI، بل يقومون بإزالته).
هل يجب علي استخدام SHA-256 أو SHA-384 أو SHA-512؟
المتصفحات تدعم الثلاثة. SHA-384 هو الاختيار الشائع - مقاومة تصادم أقوى قليلاً من SHA-256 بينما أقصر من SHA-512. الأمن العملي قابل للمقارنة. اختر واحدًا واستخدمه باستمرار.
شرح سلامة الموارد الفرعية: كيف تتحقق الصفحات من البرامج النصية التي يتم تحميلها