استضافة بيانات المستخدم بأمان في تطبيقات الويب الحديثة

David Dworken

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

الحلول الكلاسيكية لعزل المحتوى غير الموثوق به

إنّ الحلّ الكلاسيكي لعرض المحتوى الذي يتحكّم فيه المستخدم بأمان هو استخدام ما يُعرف باسم نطاقات وضع الحماية. الفكرة الأساسية هي أنّه إذا كان النطاق الأساسي لتطبيقك هو example.com، يمكنك عرض كل المحتوى غير الموثوق به على exampleusercontent.com. بما أنّ هذين النطاقَين من مواقع إلكترونية مختلفة، لا يمكن لأي محتوى ضار على exampleusercontent.com التأثير في example.com.
يمكن استخدام هذا النهج لعرض جميع أنواع المحتوى غير الموثوق به بأمان، بما في ذلك الصور والمحتوى الذي يتم تنزيله وHTML. قد لا يبدو أنّه من الضروري استخدام هذا الإجراء للصور أو عمليات التنزيل، ولكنّه يساعد في تجنُّب المخاطر الناتجة عن التجسّس على المحتوى، خاصةً في المتصفّحات القديمة.
تُستخدَم نطاقات وضع المحاكاة على نطاق واسع في المجال وقد أثبتت فعاليتها لفترة طويلة. ولكنّ لها عيوبان رئيسيتان:

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

تجدر الإشارة أيضًا إلى أنّ نطاقات وضع الحماية الاختبارية تساعد في الحدّ من مخاطر التصيّد الاحتيالي لأنّ الموارد مقسّمة بوضوح على نطاق معزول.

حلول حديثة لعرض محتوى المستخدمين

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

الطريقة 1: عرض محتوى المستخدمين غير النشطين

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

• اضبط دائمًا رأس Content-Type على نوع MIME معروف يتوافق مع جميع المتصفّحات ويضمن عدم احتوائه على محتوى نشط (في حال الشك، يمكنك استخدام application/octet-stream كخيار آمن).
• بالإضافة إلى ذلك، اضبط دائمًا عناوين الاستجابة أدناه لضمان عزل المتصفح للاستجابة بالكامل.

X-Content-Type-Options: nosniff

Content-Disposition: attachment; filename="download"

Content-Security-Policy: sandbox

Content-Security-Policy: default-src ‘none'

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 لتفعيل عزل المواقع الإلكترونية.

الطريقة 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، سبق أن نقلنا العديد من المنتجات لاستخدام هذه الحلول، ولدينا المزيد من عمليات النقل المخطّط لها في العام المقبل.