شرح SRI: البصمة الرقمية لأصول موقعك الإلكتروني

في جملة واحدة

سلامة الموارد الفرعية (SRI) هي ميزة أمان تتيح للمتصفحات التحقق من أن الملفات التي تجلبها من مصادر خارجية، مثل شبكات توصيل المحتوى (CDNs)، لم يتم التلاعب بها سرًا.

المشكلة التي يحلها

تخيل معي هذا السيناريو: أنت تبني تطبيق ويب جديد وأنيق. لجعله سريعًا، تستخدم شبكة توصيل محتوى (CDN) لتقديم المكتبات الشائعة مثل React أو Vue أو حتى بعض الخطوط الفاخرة. هذه ممارسة معتادة. يحصل المستخدمون على تجربة أسرع لأن الملف غالبًا ما يكون مخبأً (cached) في متصفحهم من زيارة موقع آخر، أو يتم تقديمه من سيرفر أقرب إليهم جغرافيًا. الكل رابح، صحيح؟

غالبًا. لكنك أدخلت للتو عنصر ثقة هائل. أنت تثق بأن مزود الـ CDN سيقدم دائمًا الملف بالضبط الذي كنت تنويه. ماذا لو تم اختراق هذا الـ CDN؟ يمكن للمهاجم استبدال ملف react.min.js الودود والمفيد بنسخة خبيثة: react.min.js-plus-a-crypto-miner-and-password-stealer.

فجأة، هذا الكود الخبيث يعمل على موقعك أنت، مع الثقة الكاملة من متصفحات المستخدمين. يمكنه سرقة بيانات تسجيل الدخول، تشويه صفحاتك، أو تجنيد زوارك في شبكة بوت نت (botnet). هذا هجوم كلاسيكي على سلسلة التوريد (supply-chain attack)، وهو مرعب لأنك لم ترتكب أي خطأ على سيرفرك الخاص. كل ما فعلته هو أنك وثقت في الطرف الخطأ في الوقت الخطأ.

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

كيف تعمل من وراء الكواليس

الـ SRI هو زواج ذكي بين سمة (attribute) بسيطة في HTML وبعض المبادئ التشفيرية الجادة. دعنا نحللها.

سمة `integrity`

يبدأ السحر بسمة جديدة يمكنك إضافتها إلى وسوم <script> و <link>. اسمها، كما هو متوقع، integrity.

<script
  src="https://code.jquery.com/jquery-3.6.0.min.js"
  integrity="sha384-oBqDVmMz9ATKxIep9tiCxS/Z9fNfEXiDAYTujMAeBAsjFuCZSmKbSSUnQlmh/jp3"
  crossorigin="anonymous"></script>

تحتوي هذه السمة على سلسلة نصية تتكون من جزأين: بادئة لخوارزمية الهاش (هنا، sha384-) و hash مشفر بترميز Base64. هذه هي "البصمة الرقمية" للملف الذي تتوقع استقباله.

الهاش (Hash): بصمة رقمية

دالة الهاش المشفرة هي خوارزمية رياضية تأخذ مدخلًا (مثل محتوى ملف JavaScript بأكمله) وتنتج سلسلة قصيرة وثابتة الحجم من الأحرف، تسمى الهاش (hash). فكر فيها كأنها checksum خارقة.

هذه الهاشات لها بعض الخصائص الحاسمة:

حتمية (Deterministic): نفس الملف المدخل سينتج دائمًا نفس الهاش تمامًا.
تأثير الانهيار (Avalanche Effect): غيّر حرفًا واحدًا فقط في الملف المدخل—أضف مسافة، غيّر اسم متغير—وسيكون الهاش الناتج مختلفًا تمامًا وغير قابل للتمييز.
أحادية الاتجاه (One-way): من المستحيل عمليًا عكس العملية. لا يمكنك أخذ الهاش ومعرفة محتوى الملف الأصلي.

يدعم معيار SRI ثلاث خوارزميات هاش آمنة: SHA-256، SHA-384، و SHA-512. يشير الرقم إلى طول الهاش بالبت، وكلما كان أكبر كان أقوى بشكل عام. SHA-384 هو خيار ممتاز وشامل.

لذلك، عندما تكون على وشك الربط بملف من CDN، تقوم أولاً بإنشاء الهاش الخاص به. أنت في الأساس تأخذ لقطة للملف في تلك اللحظة وتقول للمتصفح، "هذا ما يبدو عليه ملف jquery-3.6.0.min.js الحقيقي."

سمة `crossorigin`

هل ترى crossorigin="anonymous" في المثال؟ ليست مجرد زينة؛ إنها إلزامية. لكي يتمكن المتصفح من جلب مورد من مصدر مختلف (origin) (على سبيل المثال، موقعك my-app.com يجلب سكريبت من code.jquery.com) وفحص محتوياته للتحقق من SRI، فإنه يحتاج إلى إذن عبر مشاركة الموارد عبر المصادر (CORS).

ضبط crossorigin="anonymous" يخبر المتصفح بإجراء الطلب دون إرسال أي بيانات اعتماد للمستخدم مثل الكوكيز (cookies) أو ترويسات مصادقة HTTP. هذا أمر ضروري للأمان والخصوصية. إذا نسيت هذه السمة، سيرفض المتصفح إجراء فحص السلامة وسيمنع ببساطة تحميل المورد، مما يؤدي إلى تعطل الموقع.

تجميع كل شيء معًا: قائمة تحقق المتصفح

عندما يواجه المتصفح وسمًا يحتوي على سمة integrity، فإنه يتبع هذا البروتوكول الصارم:

يرى وسم <script> ويلاحظ سمات src و integrity و crossorigin.
يرسل طلبًا للملف الموجود في رابط src. بفضل crossorigin، يكون هذا الطلب من نوع CORS.
يتم تنزيل الملف.
الأهم من ذلك، قبل تنفيذ أي شيء، يقوم المتصفح بحساب الهاش الخاص به لمحتوى الملف الذي تم تنزيله، باستخدام نفس الخوارزمية المحددة في سمة integrity (على سبيل المثال، sha384).
ثم يقارن الهاش الذي حسبه للتو مع الهاش الذي قدمته أنت في السمة.
إذا تطابقا: يا للروعة! الملف أصلي. يقوم المتصفح بتنفيذ السكريبت أو تطبيق ورقة الأنماط (stylesheet).
إذا لم يتطابقا: إنذار أحمر! يفترض المتصفح أنه تم التلاعب بالملف. يتجاهل الملف تمامًا ولا يقوم بتنفيذه. ثم يطلق خطأ Failed to find a valid digest في وحدة تحكم المطور (developer console). قد يبدو موقعك معطلاً (على سبيل المثال، رسم بياني أو خط مفقود)، لكنك نجحت في تفادي رصاصة.

قصص من الواقع

لوحة تحكم التحليلات المشوهة

اعتمد فريق تسويق على لوحة تحكم تستخدم مكتبة رسوم بيانية من طرف ثالث، يتم جلبها من CDN غير مشهور، لتصوير بيانات حملاتهم. المطور، بعد أن قرأ للتو عن أفضل ممارسات الأمان، أضاف هاشات SRI إلى وسم <script> الخاص بالمكتبة. في صباح أحد أيام الاثنين، تعرض الـ CDN لاختراق قصير. استبدل المهاجم مكتبة الرسوم البيانية الشهيرة بسكريبت يعرض فقط وجهًا فنيًا ضخمًا وساخرًا من نوع ASCII art.

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

الدرس المستفاد: الـ SRI يحول كارثة أمنية محتملة إلى مشكلة توفر يمكن احتواؤها.

مُعدِّن العملات المشفرة المتسلل

كانت هناك مكتبة أدوات JavaScript خفيفة وشائعة مستضافة على CDN مجاني، مفضلة لدى المطورين المستقلين. تمكن مهاجم من الوصول إلى الـ CDN وقام بتعديل ملف المكتبة، مضيفًا بضعة أسطر من الكود المشوش (obfuscated) الذي يشغل مُعدِّن عملات مشفرة بتقنية WebAssembly. لم يتغير حجم الملف إلا بالكاد، وظلت الوظائف الأساسية للمكتبة تعمل بشكل مثالي.

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

الدرس المستفاد: الـ SRI لا يكتشف فقط التشويهات الواضحة ولكن أيضًا الهجمات الطفيلية الدقيقة التي يمكن أن تضر بسمعة موقعك.

تحديث الخط المنسي

أصر مصمم على استخدام إصدار معين من خط من مسبك خطوط (font foundry) تابع لجهة خارجية، يتم تقديمه عبر الـ CDN الخاص بهم. قام المطور بنسخ وسم <link> بجدية، مع هاش الـ SRI الخاص به. أُطلق الموقع وبدا رائعًا. بعد ستة أشهر، قام المسبك بتحديث ملف الخط لإضافة رموز عملات جديدة وتحسين تقنين الأحرف (kerning). كان تحديثًا شرعيًا ومفيدًا.

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

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

أخطاء وفخاخ شائعة

نسيان crossorigin="anonymous". هذا هو الخطأ رقم 1. بدونه، لا يملك المتصفح إذن CORS لفحص المورد، لذلك لأسباب أمنية، يقوم ببساطة بحظره. لا يحدث أي فحص سلامة. يفشل تحميل السكريبت أو الستايل الخاص بك ببساطة.
عمل هاش للشيء الخطأ. يجب عليك عمل هاش لمحتوى الملف الدقيق الذي يستقبله المتصفح. لا تقم بعمل هاش لنسخة محلية غير مضغوطة من سكريبت إذا كنت ترتبط بالنسخة المصغرة (minified) على الـ CDN. لا تقم بعمل هاش لسلسلة الـ URL نفسها. أنت بحاجة إلى هاش لمحتوى (body) الملف.
استخدام خوارزميات هاش ضعيفة. خوارزميات MD5 و SHA-1 بها ثغرات معروفة ولا ينبغي استخدامها لأغراض أمنية. يتطلب المعيار من المتصفحات دعم SHA-256 و SHA-384 و SHA-512 على الأقل. التزم بها.
عدم تحديث الهاش بعد تحديث شرعي. الـ SRI ميزة وليس عيبًا. إذا تم تحديث الملف الذي ترتبط به لأي سبب، فيجب عليك حتماً إنشاء هاش سلامة جديد وتحديث سمة integrity في ملف الـ HTML الخاص بك. سيؤدي عدم القيام بذلك إلى حظر المورد.
الاعتقاد بأنه يحمي سيرفرك الخاص. تم تصميم SRI للتحقق من صحة الموارد من أطراف ثالثة. إذا تمكن مهاجم من اختراق سيرفرك بما يكفي لتغيير ملفات HTML الخاصة بك، فيمكنه ببساطة تغيير هاش SRI ليتوافق مع السكريبت الخبيث الخاص به. لا يوفر أي فائدة للموارد من نفس المصدر (same-origin).

لماذا يجب أن يكون على رادارك

يجب أن تفكر في SRI في كل مرة تكتب فيها <script src="..."> أو <link rel="stylesheet" href="..."> يشير إلى دومين لا تتحكم فيه.

إنه جزء أساسي من أمان الويب الحديث. في عالم مبني على NPM و CDNs وشبكة معقدة من الاعتماديات على أطراف ثالثة، فإن سلسلة التوريد الخاصة بك هي سطح هجوم ضخم. الـ SRI هو أحد أبسط الأدوات وأكثرها فعالية لتقوية هذا السطح. إنه خط دفاعك الأول ضد CDN مخترق. بالاقتران مع سياسة أمان المحتوى (CSP)، فإنه يوفر حماية قوية ومتعددة الطبقات.

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

تعمق أكثر

MDN Web Docs: Subresource Integrity - المرجع النهائي للمطورين.
W3C Recommendation: Subresource Integrity - المواصفات التقنية الرسمية. إذا كنت تريد أعمق الغوصات، فهذا هو المكان.
Can I use... Subresource Integrity - جدول توافق المتصفحات المحدث لـ SRI.
Wikipedia: Cryptographic hash function - لفهم أفضل لسحر "البصمات" وراء SRI.
Scott Helme: Subresource Integrity - مقال رائع من خبير أمني حول ماذا ولماذا وكيف.