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

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 لإرسال المحتوى غير الموثوق به إلى وحدة التحكم من أجل عرضه.
• يتم تحويل المحتوى المعروض إلى Blob وعرضه داخل إطار iframe في وضع الحماية.

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

الخاتمة

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