أدوات المطورين · SHA حاسبة التجزئة
سلامة الموارد الفرعية: كيف تستخدم المتصفحات SHA-384 للتحقق من البرامج النصية
· خلفية
شا-256 base64 متصفح API حماية
تسمح سمة التكامل للمتصفح برفض البرنامج النصي CDN الذي تغيرت وحدات البايت الخاصة به. يشرح هذا المنشور تنسيق السمة، ولماذا SHA-384 في base64 هو الاختيار الشائع، وما لا يمكن لـ SRI الحماية منه.
CDN الذي يمكن أن يخدم أي شيء — تم تصميم مخاطر سلسلة التوريد SRI من أجل
يمكن أن تحمل علامة البرنامج النصي الموجودة على صفحة الويب سمة التكامل: `<script src="https://cdn.example.com/lib.js" integrity="sha384-..."></script>`. قيمة التكامل عبارة عن ملخص تشفير لبايتات البرنامج النصي. عندما يقوم المتصفح بتنزيل البرنامج النصي، فإنه يحسب ملخص البايتات المستلمة ويقارن مع سمة التكامل. إذا كانت متطابقة، فسيتم تحميل البرنامج النصي. إذا لم تكن متطابقة، فإن المتصفح يرفض تحميله ويبلغ عن الفشل في وحدة التحكم. وهذا يحمي من CDN الذي يعرض تعليمات برمجية معدلة، أو من مهاجم الشبكة الذي يعترض الاستجابة ويغيرها.
سلامة الموارد الفرعية (SRI) هي إحدى مواصفات W3C التي تنطبق على البرامج النصية وأوراق الأنماط. إنه ضمان التشفير الوحيد الذي يمكن للمتصفح تقديمه بشأن محتوى المورد عبر الأصل: يجب أن تتطابق البايتات مع الملخص، أو سيتم رفض المورد. وهذا لا يثبت من قام بإنشاء المورد، ولكنه لم يتغير منذ أن تم حساب الملخص. بالنسبة إلى المورد الذي يتم تقديم أكثر من HTTPS من CDN حسن السمعة، يوفر الملخص ضمانًا ضد CDN الذي يتم اختراقه أو تقديم محتوى قديم مخبأ لك على وجه التحديد.
سمة التكامل - بادئة الخوارزمية، والواصلة، وملخص Base64، ودعم التجزئة المتعددة
سمة التكامل لها تنسيق محدد: اسم الخوارزمية، الواصلة، الملخص في base64. مثال: `integrity="sha384-JZDdQnrrAMe+sxxpn47in+PwhkxrCrt4SNvt+xWqV3zPJUkeFF0Qq/wNtuvNqPP5"`. يمكن أن يكون اسم الخوارزمية SHA-256 أو SHA-384 أو SHA-512. Base64 هو الترميز، وليس الست عشري؛ يعد هذا اختيارًا متعمدًا وفقًا لمواصفات SRI. Base64 أكثر إحكاما من الشكل السداسي (حوالي 33% أقصر لنفس الملخص)، وهو أمر مهم عند التضمين في سمات HTML. تفصل الواصلة اسم الخوارزمية عن الملخص. يمكن إدراج قيم تكامل متعددة، مفصولة بمسافات: إذا تطابق أي منها، يتم قبول المورد.
لماذا SHA-384؟ تسمح مواصفات SRI بـ SHA-256 وSHA-384 وSHA-512. أصبح SHA-384 هو الخيار الافتراضي للمجتمع لأنه يوفر حجمًا /security. SHA-256 أصغر (32 bytes، 44 حرفًا في base64) ولكن SHA-384 أوسع (48 bytes، 64 حرفًا في base64) ولم يؤدي إلى زيادة حجم السمة بشكل ملموس مقارنة بـ SHA-256. SHA-512 متاح ولكن نادرًا ما يتم استخدامه لأن ملخصه الأكبر لا يبدو ضروريًا لحالة الاستخدام هذه. يعد اختيار SHA-384 أمرًا تاريخيًا وعمليًا، وليس انعكاسًا لخصائص الأمان الفائقة (جميعها الثلاثة قوية من الناحية التشفيرية لهذا الغرض).
يتم تقديم SHA-384 وإنتاج المادة الأساسية 64 المطلوبة؛ لا يتم استنتاج تفضيل المجتمع من الأداة
ترميز Base64 في SRI هو base64 القياسي، وليس base64url. يستخدم base64 القياسي أحرف + و/، والتي تكون صالحة في سمات HTML بدون ترميز النسبة المئوية، على الرغم من أن لها معاني خاصة في عناوين URL وبيانات النموذج. تم تصميم التنسيق SRI لسمات HTML، وليس عناوين URL، لذا فإن base64 القياسي مناسب. إذا كنت تقوم بإنشاء قيمة تكامل يدويًا، فيمكنك حساب الملخص SHA-384 (سلسلة من البايتات)، ثم تشفير تلك البايتات كـ base64 القياسي، ثم إضافة `sha384-` مسبقًا ولصقها في سمة التكامل.
يقوم المتصفح بتنفيذ نفس الخطوات في الاتجاه المعاكس: استخراج base64 من سمة التكامل، وفك التشفير إلى وحدات البايت لاستعادة الملخص، وحساب SHA-384 من وحدات بايت البرنامج النصي التي تم تنزيلها ومقارنة قيمتي الملخص. يجب أن تتطابق تمامًا؛ يؤدي الاختلاف بمقدار بت واحد في الملخص إلى الرفض. لا يوجد مطابقة غامضة أو اعتماد جزئي: فالنزاهة ثنائية.
يتطلب سلوك SRI عبر الأصل وثائق المتصفح خارج حاسبة التجزئة هذه
SRI يتطلب CORS على الاستجابات عبر الأصل. إذا قمت بتحميل برنامج نصي من أصل مختلف، فيجب أن يستجيب الخادم بـ `Access-Control-Allow-Origin: *` أو رأس أصل محدد يتضمن رأسك. بدون رؤوس CORS، لا يمكن للمتصفح التحقق من SRI، لأنه بدون CORS لا يمكنه التأكد من أن نص الاستجابة يطابق ما ينوي الخادم إرساله. رؤوس CORS هي بيان الخادم بأن هذه الاستجابة آمنة للتحقق منها؛ SRI هو التحقق من صحة البايتات. إنهم يشكلون معًا التزامًا بسلسلة التوريد: يسمح لك الخادم بالتحقق من المحتوى، وأنت تفعل ذلك.
إذا كان البرنامج النصي عبر الأصل يفتقر إلى رؤوس CORS ويحتوي على سمة التكامل، فسيقوم المتصفح بتنزيله (إذا كانت البرامج النصية من هذا الأصل مسموح بها بواسطة CSP الخاص بالموقع)، لكنه لن يتحقق من التكامل. سيتم تحميل البرنامج النصي كما لو كانت سمة التكامل غائبة. وهذا ليس فشلاً لـ SRI؛ إنها حدود أمنية: لا يمكنك التحقق من إجابة لا يمكنك قراءتها.
ماذا يحدث في حالة عدم التطابق — يقوم المتصفح بحظر المورد والتقارير في وحدة التحكم
عندما يكتشف المتصفح عدم تطابق التكامل، فإنه يرفض تنفيذ البرنامج النصي ويسجل رسالة في وحدة تحكم المتصفح. تقوم الرسالة عادةً بتسمية URL والتجزئة المتوقعة والتجزئة المحسوبة. الفشل ذري: إما أن يتم تحميل المورد كما هو أو يتم رفضه بالكامل. لا يوجد تحميل جزئي أو احتياطي. إذا كان موقع ويب يعتمد على هذا البرنامج النصي وتم رفضه، فقد يتعطل الموقع. وهذا أمر مقصود: تقديم تعليمات برمجية خاطئة أسوأ من عدم تقديم تعليمات برمجية، كما أن حالات الفشل الصامتة تمكن الهجمات من الاستمرار إلى أجل غير مسمى.
يعد اختبار إعداد SRI أمرًا مباشرًا: افتح وحدة تحكم المتصفح، وقم بتحميل الصفحة وابحث عن الرسائل المتعلقة بعدم تطابق التكامل. إذا رأيت عدم تطابق، فقارن التجزئة المحسوبة المعروضة في وحدة التحكم بالتجزئة الموجودة في سمة التكامل الخاصة بك. إذا لم تكن متطابقة، أعد الحساب: ربما تم تحديث البرنامج النصي وتحتاج إلى ملخص جديد.
مثال عملي - حساب ملخص لبرنامج نصي وتنسيقه في قيمة تكامل، بما في ذلك خطوة base64
يتطلب حساب ملخص SRI يدويًا فقط بايتات البرنامج النصي وأداة التجزئة. قم بتنزيل البرنامج النصي، والصقه في حاسبة التجزئة ToolAcre SHA، وحدد SHA-384، وانسخ إخراج base64 (وليس السداسي)، وألحق `sha384-` مسبقًا، والصقه في سمة التكامل. إذا كان البرنامج النصي كبيرًا، فإن استخدام cur أو wget لحفظه في ملف ثم قراءة الملف يكون أسرع من لصقه. بالنسبة للبرامج النصية المضمنة (في علامة `<script>` في HTML بدلاً من URL)، لا ينطبق SRI؛ البرامج النصية المضمنة موثوقة دائمًا حسب التعريف. SRI مخصص للموارد الخارجية.
مثال عملي: لنفترض أنك تريد تحميل jQuery من CDN مع SRI. ابحث عن البرنامج النصي URL، وقم بتنزيله (أو استخدم الضفيرة لجلبه)، والصق البايتات في الآلة الحاسبة أو استخدم `sha384sum` في سطر الأوامر، واحصل على الملخص SHA-384 كـ base64، وقم بتنسيقه كـ `sha384-[base64-digest]`. الصق في سمة تكامل علامة البرنامج النصي. قم بتحميل الصفحة وتحقق من عدم ظهور أخطاء في وحدة التحكم.
ما لا يغطيه هذا هو النصوص البرمجية التي تتغير عمدًا، والمواقع مثل ToolAcre التي لا تقوم بتحميل أي نصوص برمجية خارجية على الإطلاق وبالتالي ليس لديها ما يمكن تثبيته
SRI لا يوفر الحماية ضد جميع هجمات سلسلة التوريد. فهو يحمي من تغيير وحدات البايت بعد حساب الملخص، ولكن ليس من حساب الملخص من تعليمات برمجية مخترقة في البداية. إذا تم اختراق CDN قبل حساب الملخص، فلن يتمكن SRI من مساعدتك. يكون الملخص جديرًا بالثقة بقدر المصدر الذي قمت بحسابه منه. للحصول على أقصى قدر من الضمان، قم بحساب الملخصات من المصدر الأصلي (إصدارات GitHub الخاصة بالمكتبة، على سبيل المثال) واستخدم تلك الملخصات عند التحميل من CDN. يصبح الملخص التزامًا من المشرف خلال عملية الإصدار.
SRI لا يحمي أيضًا من الشبكة المخترقة في اللحظة التي تقوم فيها بحساب الملخص، أو من جهاز التطوير المخترق. إنه يحمي فقط من التغييرات التي تطرأ على البرنامج النصي بين وقت إنشاء الملخص والوقت الذي يقوم فيه المتصفح بتحميل البرنامج النصي. للحصول على ضمان مستمر، تستخدم بعض عمليات النشر توقيع الإصدار بالإضافة إلى SRI: يتم توقيع الإصدار بواسطة مفتاح المشرف، وتتحقق من التوقيع، وتحسب الملخص من وحدات البايت التي تم التحقق منها وتستخدم ذلك في SRI.
لا تؤكد هذه المقالة على مخزون النصوص البرمجية الخارجية لـ ToolAcre على مستوى الموقع من مصادر التجزئة
تُصدر حاسبة التجزئة ToolAcre SHA الملخص في base64 القياسي مباشرةً (مثل إخراج `base64` من الدالة `toBase64()`). للتحويل إلى تنسيق SRI، أضف اسم الخوارزمية وواصلة: `sha256-` أو `sha384-` أو `sha512-`. لا تقوم الآلة الحاسبة بتطبيق هذه البادئة تلقائيًا لأن التجزئات تظهر في العديد من السياقات (git وDocker وnpm وعناوين URL) حيث يكون اسم الخوارزمية منفصلاً أو مشفرًا بشكل مختلف. الحدود واضحة: تقوم الآلة الحاسبة بتجزئة النص UTF-8 الذي تقوم بلصقه، وليس الملفات أو المفاتيح الثنائية. يقوم بإخراج كلاً من hex وbase64. اخترت ما تريد استخدامه بناءً على السياق الخاص بك. بالنسبة إلى SRI، فإن Base64 مطلوب بموجب المواصفات. بالنسبة إلى git والأدوات الأخرى، يعتبر الملف السداسي عشريًا تقليديًا. بالنسبة إلى npm وGo، يتم استخدام base64. خيار الترميز لك؛ بايتات الملخص هي نفسها.
يظل SRI واحدًا من عمليات التحقق التشفيرية القليلة التي يمكن للمتصفح إجراؤها من جانب العميل دون سلطة مركزية. تلخص عملية الحوسبة بنفسك باستخدام أداة موثوقة مثل الآلة الحاسبة SHA الخاصة بـ ToolAcre والتحقق منها مقابل الموارد المحملة هي طريقة يسهل الوصول إليها لتقوية موقع الويب ضد بعض هجمات سلسلة التوريد. الحماية جيدة مثل الملخص فقط؛ أعد الحساب بعد كل تحديث للمورد الخارجي واختبر أن يقوم المتصفح بتحميل البرنامج النصي دون رفضه.