الخميس 16 كانون الثاني (يناير)، 2020
هذه مشاركة متعدّدة من مدوّنة مطوّري برامج Chromium وهي ترتبط بشكل خاص بكيفية تأثير التغييرات التي تطرأ على Chrome على آلية عمل موقعك الإلكتروني للمستخدمين في المستقبل.
في شهر أيار (مايو)، أعلن Chrome عن نموذج آمن تلقائيًا لملفات تعريف الارتباط، تم تفعيله من خلال نظام تصنيف جديد لملفات تعريف الارتباط (المواصفات). تشكّل هذه المبادرة جزءًا من جهودنا المتواصلة لتحسين مستوى الخصوصية والأمان على الويب.
يخطط Chrome لتنفيذ النموذج الجديد على Chrome 80 في شباط (فبراير) 2020. أشارت شركتا Mozilla وMicrosoft أيضًا إلى رغبتهما في تنفيذ النموذج الجديد على Firefox وEdge على المخططات الزمنية الخاصة بهم. على الرغم من أن تغييرات Chrome لن تنفَّذ قبل بضعة أشهر، من المهم أن يقيّم مطوّرو البرامج الذين يديرون ملفات تعريف الارتباط جاهزية هذه التغييرات اليوم. تشرح مشاركة المدونة هذه المفاهيم العالية المستوى. يُرجى الاطّلاع على شرح ملفات تعريف ارتباط SameSite على web.dev للحصول على إرشادات من مطوّري البرامج.
فهم سياق ملفات تعريف الارتباط على جميع المواقع الإلكترونية وعلى الموقع الإلكتروني نفسه
تدمج المواقع الإلكترونية عادةً الخدمات الخارجية لعرض الإعلانات واقتراحات المحتوى والأدوات التابعة لجهات خارجية وعمليات تضمين اجتماعية وغيرها من الميزات. أثناء تصفُّح الويب، قد تخزّن هذه الخدمات الخارجية ملفات تعريف الارتباط في المتصفّح، وبالتالي تستخدم ملفات تعريف الارتباط هذه لتقديم تجارب مخصَّصة أو قياس تفاعل الجمهور. يرتبط كل ملف تعريف ارتباط بنطاق خاص به. إذا كان النطاق المرتبط بملف تعريف ارتباط يطابق خدمة خارجية وليس الموقع الإلكتروني في شريط العناوين الخاص بالمستخدم، يُعتبر ذلك سياقًا على مواقع إلكترونية مختلفة (أو"جهة خارجية" ).
تشمل حالات الاستخدام الأقل وضوحًا على مواقع إلكترونية مختلفة الحالات التي تستخدم فيها جهة لديها مواقع إلكترونية متعدّدة ملف تعريف ارتباط واحد على تلك المواقع. ومع أنّ الجهة نفسها تمتلك ملف تعريف الارتباط والمواقع الإلكترونية، يُعتبر ذلك سياقًا على مواقع إلكترونية مختلفة أو "جهة خارجية" عندما لا يتطابق نطاق ملف تعريف الارتباط مع المواقع الإلكترونية التي يتم الوصول منها إلى ملف تعريف الارتباط.
عندما يصل أحد الموارد الخارجية على صفحة ويب إلى ملف تعريف ارتباط لا يتطابق مع نطاق الموقع الإلكتروني، فهذا سياق مواقع إلكترونية مختلفة أو "جهة خارجية".
وفي المقابل، يتم الوصول إلى ملف تعريف الارتباط في سياق الموقع الإلكتروني نفسه (أو "الطرف الأول") عندما يتطابق نطاق ملف تعريف ارتباط مع نطاق الموقع الإلكتروني في شريط العناوين الخاص بالمستخدم. يتم استخدام ملفات تعريف الارتباط الخاصة بالموقع الإلكتروني نفسه عادةً للحفاظ على تسجيل دخول المستخدمين إلى مواقع إلكترونية فردية، ولتذكّر إعداداتهم المفضّلة وتوفير إحصاءات المواقع الإلكترونية.
عندما يصل أحد الموارد على صفحة ويب إلى ملف تعريف ارتباط يتطابق مع الموقع الإلكتروني الذي يزوره المستخدم، يكون هذا سياق الموقع الإلكتروني نفسه أو "الطرف الأول".
نموذج جديد لأمان ملفات تعريف الارتباط والشفافية
حاليًا، في حال كان الهدف من ملف تعريف الارتباط أن يتم الوصول إليه في سياق الطرف الأول فقط، سيكون لدى مطوّر البرامج
خيار تطبيق أحد الإعدادَين (SameSite=Lax
أو
SameSite=Strict
) لمنع الوصول الخارجي. وعدد قليل جدًا
من مطوّري البرامج يتّبعون هذه الممارسات المقترَحة، ما يؤدي إلى ترك عدد كبير من ملفات تعريف الارتباط على الموقع الإلكتروني نفسه
عرضة للتهديدات بدون داعٍ، مثل هجمات
تزوير الطلبات من مواقع إلكترونية مختلفة.
لحماية المزيد من المواقع الإلكترونية ومستخدميها، يفترض النموذج الجديد الآمن تلقائيًا أن جميع ملفات تعريف الارتباط
يجب حمايتها من الوصول الخارجي ما لم يُذكر خلاف ذلك. على مطوّري البرامج استخدام إعداد جديد
لملفات تعريف الارتباط، وهو SameSite=None
، لتحديد ملفات تعريف الارتباط بغرض الوصول إلى مواقع إلكترونية
مختلفة. عند توفّر السمة SameSite=None
، يجب استخدام
سمة آمنة إضافية كي لا يتم الوصول إلى ملفات تعريف الارتباط على مواقع إلكترونية مختلفة إلا من خلال اتصالات HTTPS.
لن يساعد هذا الإجراء في الحد من جميع المخاطر المرتبطة بالوصول إلى مواقع إلكترونية مختلفة، ولكنه سيوفّر حماية
من هجمات الشبكة.
إنّ الإعلان الصريح عن ملفات تعريف ارتباط خاصة بمواقع إلكترونية مختلفة يوفّر المزيد من الشفافية والخيارات للمستخدمين، بالإضافة إلى تقديمه مزايا أمان فورية. على سبيل المثال، يمكن أن توفّر المتصفحات للمستخدمين عناصر تحكّم دقيقة لإدارة ملفات تعريف الارتباط التي لا يمكن الوصول إليها إلا من خلال موقع إلكتروني واحد بشكل منفصل عن ملفات تعريف الارتباط التي يمكن الوصول إليها من خلال مواقع إلكترونية متعددة.
كبح المواقع المضلِّلة على Chrome ابتداءً من شباط (فبراير) 2020
في الإصدار Chrome 80 الذي سيتم إصداره في فبراير، سيتعامل متصفّح Chrome مع ملفات تعريف الارتباط التي لا تتضمّن قيمة SameSite المُعلَن عنها
كملفات تعريف ارتباط SameSite=Lax
. ستكون ملفات تعريف الارتباط متاحة للوصول
الخارجي فقط إذا تضمّنت الخيار SameSite=None; Secure
، بشرط أن يتم الوصول إليها من خلال اتصالات آمنة. سيتواصل تحديث أدوات تتبّع حالة النظام الأساسي الخاص بمتصفّح Chrome لسمة
SameSite=None
والأمان
باستخدام أحدث معلومات الإطلاق.
أكّدت شركة Mozilla إتاحة استخدام نموذج تصنيف ملفات تعريف الارتباط الجديد
ونيتها بتنفيذ
متطلبات SameSite=None; Secure
لملفات تعريف الارتباط الخاصة بمواقع إلكترونية مختلفة في Firefox. وقد أعلنت
شركة Microsoft مؤخرًا أنها
تخطط لبدء تنفيذ النموذج كتجربة في Microsoft Edge 80.
كيفية التحضير: التعقيدات المعروفة
إذا كنت تدير ملفات تعريف الارتباط على مواقع إلكترونية مختلفة، عليك تطبيق سمة SameSite=None
،
إعدادات الأمان لملفات تعريف الارتباط هذه. من المفترض أن يكون التنفيذ مباشرًا لمعظم مطوّري البرامج،
إلا أننا ننصح بشدة ببدء إجراء الاختبار الآن لتحديد التعقيدات والحالات الخاصة،
مثل ما يلي:
-
لا تتوفّر القيمة None حتى الآن في جميع اللغات والمكتبات، ما يتطلّب من المطوّرين ضبط
عنوان ملف تعريف الارتباط مباشرةً. يوفر مستودع GitHub
تعليمات لتنفيذ
SameSite=None; Secure
بعدة لغات وفي مجموعة متنوعة من المكتبات وأُطر العمل. -
قد تعالج بعض المتصفّحات، بما في ذلك بعض إصدارات Chrome وSafari وUC،
قيمة
None
بطرق غير مقصودة، ما يتطلّب من المطوّرين ترميز الاستثناءات لهذه البرامج. ويشمل ذلك إصدارات Android WebViews التي تعمل بإصدارات قديمة من Chrome. في ما يلي قائمة ببرامج غير متوافقة معروفة. -
ننصح مطوّري التطبيقات بالإعلان عن إعدادات
SameSite cookie
المناسبة لـWebViews
Android وفقًا لإصدارات Chrome المتوافقة مع القيمةNone
، لكل من ملفات تعريف الارتباط التي تم الوصول إليها عبر عناوين HTTP(S) وعبر CookieManager API الخاصة بـ AndroidWebView
، علمًا أن النموذج الجديد لن يُفرض على Android WebView حتى وقت لاحق. - قد يحتاج مشرفو تكنولوجيا المعلومات في المؤسسات إلى تنفيذ سياسات خاصة لإعادة متصفّح Chrome إلى السلوك القديم مؤقتًا في حال عدم جاهزية بعض الخدمات، مثل الدخول الموحّد أو التطبيقات الداخلية، لإطلاقها في شهر شباط (فبراير).
-
إذا كانت لديك ملفات تعريف ارتباط يمكنك الوصول إليها في كل من سياق الطرف الأول والجهة الخارجية، يمكنك
استخدام ملفات تعريف الارتباط المنفصلة للحصول على مزايا الأمان لسمة
SameSite=Lax
في سياق الطرف الأول.
يقدّم شرح ملفات تعريف ارتباط SameSite إرشادات محدّدة للمواقف أعلاه، فضلاً عن قنوات لطرح المشاكل والأسئلة.
لاختبار تأثير سلوك Chrome الجديد على موقعك الإلكتروني أو ملفات تعريف الارتباط التي تديرها، يمكنك الانتقال إلى
chrome://flags
في الإصدار 76 من Chrome والإصدارات اللاحقة وتفعيل
تجربتَي "SameSite by default cookies"
و"Cookies without SameSite must be secure". بالإضافة إلى ذلك، سيتم تفعيل هذه التجارب تلقائيًا لمجموعة فرعية من مستخدمي الإصدار التجريبي 79 Chrome. قد يواجه بعض مستخدمي الإصدار التجريبي بعد تفعيل الميزات التجريبية بعض المشاكل في عدم التوافق مع الخدمات التي لا تتوافق بعد مع النموذج الجديد. ويمكن للمستخدمين إيقاف التجارب التجريبية من خلال الانتقال إلى chrome://flags
.
إذا كنت تدير ملفات تعريف الارتباط التي يتم الوصول إليها في سياق الموقع الإلكتروني نفسه فقط (ملفات تعريف ارتباط الموقع الإلكتروني نفسه)، لن تحتاج إلى اتّخاذ أي إجراء من جانبك. سيمنع Chrome تلقائيًا وصول الكيانات الخارجية إلى ملفات تعريف الارتباط هذه، حتى إذا كانت السمة SameSite غير متوفّرة أو لم يتم ضبط أي قيمة. ننصح بشدة بتطبيق قيمة SameSite مناسبة (Lax أو Strict) وعدم الاعتماد على سلوك المتصفّح التلقائي، لأنّ بعض المتصفحات لا تحمي ملفات تعريف الارتباط الخاصة بالموقع الإلكتروني نفسه تلقائيًا.
أخيرًا، إذا كانت لديك تساؤلات حول جاهزية المورّدين وغيرهم من الذين يقدّمون خدماتهم على موقعك الإلكتروني، يمكنك التحقّق من وجود تحذيرات في وحدة تحكم أدوات المطوّرين في إصدار Chrome 77 والإصدارات اللاحقة، في حال كانت الصفحة تحتوي على ملفات تعريف ارتباط على مواقع إلكترونية مختلفة لم يتم ضبط الإعدادات المطلوبة فيها:
سينفّذ بعض مقدّمي الخدمة (بما في ذلك بعض خدمات Google) التغييرات اللازمة في الأشهر التي تسبق إطلاق إصدار Chrome 80 في شباط (فبراير). ننصحك بالتواصل مع شركائك لتأكيد جاهزيتهم.