فهم نزاهة الموارد الفرعية

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

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

القليل من التاريخ

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

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

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

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

هذا هو السبب في أنك سترى روابط CDN للمكتبات المفضلة لديك باستخدام عناوين URL مثل jsdelivr.com - فهي تستخدم شبكة CDN شائعة لاستضافة الملفات حتى يرى مستخدموها فوائد الأداء.

ما الخطأ الذي يمكن أن يحدث؟

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

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

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

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

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

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

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

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

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

تجربته

إذا ذهبت إلى getbootstrap.com اليوم للحصول على رابط CDN لإصدار Bootstrap ، فأنا أعطي علامة مثل هذا:

 <script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script>

يمكنك أن ترى أن سمة src هي كما اعتدنا عليها ، وأن سمة integrity تحمل ما نعرفه الآن على أنه تجزئة.

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

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

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

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

أستطيع أن أرى أن bootstrap.min.js (وكذلك ملف jQuery الذي يحتاجه) قد تم تحميله بنجاح.

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

 <script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="sha384-SmashingMagazineIsCoolForCats" crossorigin="anonymous"></script> 

كما ترى ، لم تعد التجزئة المحددة في صفحتي تطابق الملف ، لذلك يتم حظر الملف.

استخدام SRI في مشاريعك الخاصة

يعد امتلاك هذه الإمكانية للمكتبات على شبكة CDN أمرًا رائعًا ، وإذا رأيت خيار استخدام ملف مضمن بسمة integrity ، فعليك بالتأكيد تفضيل هذا الخيار. لكن لا يقتصر الأمر على المشاريع الكبيرة على شبكات CDN ، يمكنك استخدام هذا بنفسك لمواقعك الخاصة.

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

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

توليد تجزئة

يمكنك ، كما تتوقع ، تشغيل بعض الأوامر في محطة الكمبيوتر لإنشاء تجزئة لملف. هذا المثال لكيفية القيام بذلك مأخوذ من صفحة MDN Subresource Integrity:

 cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A

هذا هو الحصول على محتوى FILENAME.js وتمريره كمدخل إلى openssl لإنشاء ملخص باستخدام sha384 ، والذي يتم تمريره بعد ذلك كمدخل إلى أمر openssl آخر لتشفير base64 النتيجة. ليس هذا الأمر معقدًا وغامضًا فحسب ، ولكنه أيضًا ليس نوعًا من الأشياء التي تريد القيام بها يدويًا في كل مرة يتغير فيها ملف JavaScript.

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

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

إذا كنت لا تزال مع Gulp ولكن لديك موقعًا ثابتًا (أو موقعًا تم إنشاؤه بشكل ثابت) ، فيمكنك استخدام gulp-sri-hash والذي سيعمل بالفعل من خلال صفحات HTML الخاصة بك وتعديل الصفحات لإضافة تجزئة عند الحاجة ، وهو أمر مفيد للغاية.

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

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

إذا كنت تستخدم CMS مثل WordPress ، فقد وجدت مكونًا إضافيًا يبدو أنه يجعل الأمر سهلاً ، على الرغم من أنني لم أجربه بنفسي. من المحتمل أن يوجهك البحث في Googling لمنصتك المفضلة باستخدام SRI أو Sub Resource Integrity إلى الاتجاه الصحيح.

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

أشياء أخرى يجب ملاحظتها

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

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

 Content-Security-Policy: require-sri-for script;

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

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

خاتمة

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

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

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