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

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 عنوانًا للتوافق مع الإصدار 11 من Internet Explorer.
• اضبط عنوان Content-Security-Policy: frame-ancestors 'none' لمنع تضمين نقطة النهاية.
• محتوى مستخدمي Sandbox على نطاق فرعي معزول من خلال:
  • عرض محتوى المستخدمين على نطاق فرعي معزول (على سبيل المثال، تستخدم 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، نقلنا العديد من المنتجات إلى هذه الحلول، ونخطّط لنقل المزيد من المنتجات خلال العام المقبل.