تحتاج العديد من تطبيقات الويب إلى عرض محتوى يتحكّم فيه المستخدم. ويمكن أن يكون ذلك بسيطًا مثل عرض الصور التي يحمّلها المستخدم (مثل صور الملف الشخصي)، أو معقّدًا مثل عرض صفحات HTML التي يتحكّم فيها المستخدم (مثل دليل تعليمي لتطوير الويب). كان من الصعب دائمًا إجراء ذلك بأمان، لذا عملنا على إيجاد حلول سهلة وآمنة يمكن تطبيقها على معظم أنواع تطبيقات الويب.
الحلول الكلاسيكية لعزل المحتوى غير الموثوق به
إنّ الحلّ الكلاسيكي لعرض المحتوى الذي يتحكّم فيه المستخدم بأمان هو استخدام ما يُعرف باسم نطاقات وضع الحماية. الفكرة الأساسية هي أنّه إذا كان النطاق الأساسي لتطبيقك هو example.com
، يمكنك عرض كل المحتوى غير الموثوق به على exampleusercontent.com
. بما أنّ هذين النطاقَين من مواقع إلكترونية مختلفة، لا يمكن لأي محتوى ضار على exampleusercontent.com
التأثير في example.com
.
يمكن استخدام هذا النهج لعرض جميع أنواع المحتوى غير الموثوق به بأمان، بما في ذلك الصور والمحتوى الذي يتم تنزيله وHTML. قد لا يبدو أنّه من الضروري استخدام هذا الإجراء مع الصور أو عمليات التنزيل، ولكنّه يساعد في تجنُّب المخاطر الناتجة عن التجسّس على المحتوى، خاصةً في المتصفّحات القديمة.
تُستخدَم نطاقات وضع المحاكاة على نطاق واسع في المجال وقد أثبتت فعاليتها لفترة طويلة. ولكنّ لها عيوبان رئيسيتان:
- غالبًا ما تحتاج التطبيقات إلى تقييد الوصول إلى المحتوى لمستخدم واحد، ما يتطلّب تنفيذ المصادقة والتفويض. وبما أنّ نطاقات وضع الحماية لا تشارك ملفات تعريف الارتباط عن قصد مع نطاق التطبيق الرئيسي، من الصعب جدًا إجراء ذلك بأمان. لتفعيل المصادقة، على المواقع الإلكترونية الاعتماد على عناوين URL للميزات، أو عليها ضبط ملفات تعريف ارتباط مصادقة منفصلة لنطاق وضع المحاكاة. تُعدّ هذه الطريقة الثانية مشكلة بشكل خاص في الويب الحديث حيث تحظر العديد من المتصفّحات ملفات تعريف الارتباط على مستوى المواقع الإلكترونية تلقائيًا.
- على الرغم من أنّ محتوى المستخدمين معزول عن الموقع الإلكتروني الرئيسي، إلا أنّه ليس معزولاً عن محتوى المستخدمين الآخرين. ويؤدي ذلك إلى خطر تعرُّض بيانات أخرى على نطاق مساحة وضع الحماية للهجوم من خلال محتوى ضار ينشئه المستخدمون (على سبيل المثال، من خلال قراءة بيانات المصدر نفسه).
تجدر الإشارة أيضًا إلى أنّ نطاقات وضع الحماية تساعد في الحدّ من مخاطر التصيّد الاحتيالي لأنّ الموارد مقسّمة بوضوح على نطاق معزول.
حلول حديثة لعرض محتوى المستخدمين
مع مرور الوقت، تطورت الويب، وأصبحت هناك الآن طرق أسهل وأكثر أمانًا لعرض المحتوى غير الموثوق به. هناك العديد من الأساليب المختلفة هنا، لذا سنوضّح حلّين يتم استخدامهما على نطاق واسع في Google حاليًا.
الطريقة 1: عرض محتوى المستخدمين غير النشطين
إذا كان الموقع الإلكتروني يحتاج فقط إلى عرض محتوى المستخدمين غير النشطين (أي المحتوى الذي لا يكون بتنسيق HTML أو JavaScript، مثل الصور والمحتوى الذي يتم تنزيله)، يمكن إجراء ذلك الآن بأمان بدون نطاق مساحة محايدة معزولة. هناك خطوتان رئيسيتان:
- اضبط دائمًا رأس
Content-Type
على نوع MIME معروف يتوافق مع جميع المتصفّحات ويضمن عدم احتوائه على محتوى نشط (في حال الشك، يمكنك استخدامapplication/octet-stream
كخيار آمن). - بالإضافة إلى ذلك، اضبط دائمًا عناوين الاستجابة أدناه لضمان عزل المتصفح للاستجابة بالكامل.
عنوان الاستجابة | Purpose |
---|---|
X-Content-Type-Options: nosniff |
منع فحص المحتوى |
Content-Disposition: attachment; filename="download" |
بدء عملية تنزيل بدلاً من عرض المحتوى |
Content-Security-Policy: sandbox |
وضع المحتوى في بيئة اختبارية كما لو كان معروضًا على نطاق منفصل |
Content-Security-Policy: default-src ‘none' |
إيقاف تنفيذ JavaScript (وتضمين أي موارد فرعية) |
Cross-Origin-Resource-Policy: same-site |
منع تضمين الصفحة في جميع المواقع الإلكترونية |
يضمن هذا المزيج من الرؤوس أنّه لا يمكن لتطبيقك تحميل الاستجابة إلا كمورد فرعي أو تنزيلها كملف من قِبل المستخدم. بالإضافة إلى ذلك، توفّر العناوين طبقات متعددة من الحماية ضد أخطاء المتصفّح من خلال عنوان CSP sandbox وتقييد default-src
. بشكل عام، يقدّم الإعداد الموضّح أعلاه درجة عالية من الثقة بأنّ الردود التي يتم عرضها بهذه الطريقة لا يمكن أن تؤدي إلى ثغرات في حقن البيانات أو عزل البيانات.
الدفاع في العمق
على الرغم من أنّ الحلّ أعلاه يمثّل دفاعًا كافيًا بشكل عام ضد هجمات XSS، هناك عدد من إجراءات التحصين الإضافية التي يمكنك تطبيقها لتوفير طبقات إضافية من الأمان:
- اضبط رأس
X-Content-Security-Policy: sandbox
للتوافق مع IE11. - اضبط عنوان
Content-Security-Policy: frame-ancestors 'none'
لحظر تضمين نقطة النهاية. - محتوى المستخدم في مساحة الاختبار على نطاق فرعي معزول من خلال:
- عرض محتوى المستخدم على نطاق فرعي معزول (مثلاً، تستخدم Google نطاقات مثل
product.usercontent.google.com
). - اضبط
Cross-Origin-Opener-Policy: same-origin
وCross-Origin-Embedder-Policy: require-corp
لتفعيل عزل المواقع الإلكترونية.
- عرض محتوى المستخدم على نطاق فرعي معزول (مثلاً، تستخدم Google نطاقات مثل
الطريقة 2: عرض محتوى المستخدمين النشطين
يمكن أيضًا عرض المحتوى النشط بأمان (مثل صور HTML أو SVG) بدون الضعف في نهج نطاق وضع الحماية الكلاسيكي.
أبسط خيار هو الاستفادة من العنوان Content-Security-Policy: sandbox
لإخبار المتصفّح بعزل الاستجابة. على الرغم من أنّ بعض متصفّحات الويب لا تُنفّذ حاليًا عزل العمليات لمستندات وضع الحماية، من المرجّح أن تؤدي التحسينات المستمرة على نماذج عمليات المتصفّح إلى تحسين عملية فصل المحتوى المحمي في وضع الحماية عن التطبيقات المضمّنة. إذا كانت هجمات SpectreJS واختراق وحدة العرض خارج نطاق نموذج التهديدات، من المرجّح أن يكون استخدام ميزة "منطقة الحماية في خدمة مقارنة الأسعار" (CSP) هو الحلّ الكافي.
في Google، طوّرنا حلًا يمكنه عزل المحتوى النشط غير الموثوق به بالكامل من خلال تحديث مفهوم نطاقات وضع الحماية. الفكرة الأساسية هي:
- أنشئ نطاقًا جديدًا في بيئة الاختبار يتمّ إضافته إلى قائمة اللاحقات العامة. على سبيل المثال، من خلال إضافة
exampleusercontent.com
إلى قائمة PSL، يمكنك التأكّد من أنّfoo.exampleusercontent.com
وbar.exampleusercontent.com
على مستوى الموقع الإلكتروني، وبالتالي تكونا معزولتين تمامًا عن بعضهما. - يتم توجيه جميع عناوين URL التي تتطابق مع
*.exampleusercontent.com/shim
إلى ملف shim ثابت. يحتوي ملف البديل المؤقت هذا على مقتطف HTML وJavaScript قصيرَين يستمعان إلى معالِج الحدثmessage
ويعرضان أي محتوى يتلقّانه. - لاستخدام هذه الميزة، ينشئ المنتج إطارًا iframe أو نافذة منبثقة لـ
$RANDOM_VALUE.exampleusercontent.com/shim
ويستخدمpostMessage
لإرسال المحتوى غير الموثوق به إلى العنصر النائب لعرضه. - يتم تحويل المحتوى المعروض إلى Blob ويتم عرضه داخل إطار iframe في وضع الحماية.
مقارنةً بالطريقة الكلاسيكية لنطاق مساحة الاختبار، يضمن ذلك عزل كل المحتوى بالكامل على موقع إلكتروني فريد. ومن خلال جعل التطبيق الرئيسي يتعامل مع استرداد البيانات المطلوب عرضها، لم يعُد من الضروري استخدام عناوين URL للميزات.
الخاتمة
يتيح هذان الحلّان معًا نقل البيانات من نطاقات "مبادرة حماية الخصوصية" الكلاسيكية، مثل googleusercontent.com
، إلى حلول أكثر أمانًا ومتوافقة مع حظر ملفات تعريف الارتباط التابعة لجهات خارجية. في Google، سبق أن نقلنا العديد من المنتجات لاستخدام هذه الحلول، ونخطّط لنقل المزيد من المنتجات في العام المقبل.