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

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) وقيود 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 ثابت. يحتوي ملف shim هذا على مقتطف HTML ومقتطف JavaScript قصير يستمع إلى معالج أحداث message ويعرض أي محتوى يتلقاه.
• ولاستخدام ذلك، ينشئ المنتج إما إطار iframe أو نافذة منبثقة إلى $RANDOM_VALUE.exampleusercontent.com/shim ويستخدم postMessage لإرسال المحتوى غير الموثوق به إلى الواجهة من أجل عرضه.
• يتم تحويل المحتوى المعروض إلى كائن فقاعة، ويتم عرضه داخل إطار iframe في وضع الحماية.

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

الخلاصة

يتيح هذان الحلان معًا الانتقال من نطاقات وضع الحماية الكلاسيكية مثل googleusercontent.com إلى حلول أكثر أمانًا متوافقة مع حظر ملفات تعريف الارتباط التابعة لجهات خارجية. لقد نقلنا في Google العديد من المنتجات لاستخدام هذه الحلول ونخطط لإجراء المزيد من عمليات نقل البيانات في العام المقبل.