ملفات تعريف الارتباط المستخدَمة في SameSite

Rowan Merewood

يحتوي كل ملف تعريف ارتباط على زوج مفتاح/قيمة بالإضافة إلى عدد من السمات التي تتحكّم في وقت ومكان استخدام ملف تعريف الارتباط هذا.

يتيح لك تقديم السمة SameSite (المحدّدة في RFC6265bis) تحديد ما إذا كان ملف تعريف الارتباط محصورًا في سياق الطرف الأول أو سياق الموقع الإلكتروني نفسه. من المفيد فهم معنى "الموقع الإلكتروني" هنا. الموقع الإلكتروني هو مزيج من لاحقة النطاق والجزء الذي يسبقها مباشرةً. على سبيل المثال، النطاق www.web.dev هو جزء من الموقع الإلكتروني web.dev.

المصطلح الأساسي: إذا كان المستخدم على www.web.dev وطلب صورة من static.web.dev، يكون هذا الطلب من الموقع الإلكتروني نفسه.

تحدّد قائمة اللاحقات العلنية الصفحات التي يتم احتسابها على أنّها تابعة للموقع الإلكتروني نفسه. لا يعتمد ذلك على نطاقات المستوى الأعلى مثل .com فقط، بل يمكن أن يشمل أيضًا خدمات مثل github.io. يتيح ذلك اعتبار your-project.github.io وmy-project.github.io موقعَين إلكترونيَّين منفصلَين.

المصطلح الأساسي: إذا كان المستخدم على your-project.github.io وطلب صورة من my-project.github.io، يكون الطلب متعدد المواقع.

استخدام السمة SameSite للإشارة إلى استخدام ملفات تعريف الارتباط

توفّر السمة SameSite في ملف تعريف الارتباط ثلاث طرق مختلفة للتحكّم في هذا السلوك. يمكنك اختيار عدم تحديد السمة، أو يمكنك استخدام Strict أو Lax لحصر ملف تعريف الارتباط على الطلبات الواردة من الموقع الإلكتروني نفسه.

إذا ضبطت SameSite على Strict، لا يمكن إرسال ملف تعريف الارتباط إلا في سياق الطرف الأول، أي إذا كان الموقع الإلكتروني لملف تعريف الارتباط مطابقًا للموقع الإلكتروني المعروض في شريط العناوين في المتصفّح. لذلك، إذا تم ضبط ملف تعريف الارتباط promo_shown على النحو التالي:

Set-Cookie: promo_shown=1; SameSite=Strict

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

يسمح SameSite=Lax للمتصفّح بإرسال ملف تعريف الارتباط مع عمليات التنقّل هذه ذات المستوى الأعلى. على سبيل المثال، إذا أشار موقع إلكتروني آخر إلى محتوى موقعك الإلكتروني، كما هو الحال في المثال التالي حيث تم استخدام صورة قطتك مع توفير رابط يؤدي إلى مقالتك:

<p>Look at this amazing cat!</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>

مع ضبط ملف تعريف ارتباط على Lax على النحو التالي:

Set-Cookie: promo_shown=1; SameSite=Lax

عندما يطلب المتصفّح amazing-cat.png لمدونة الشخص الآخر، لا يرسل موقعك الإلكتروني ملف تعريف الارتباط. ومع ذلك، عندما ينقر القارئ على الرابط المؤدي إلى cat.html على موقعك الإلكتروني، يتضمّن هذا الطلب ملف تعريف الارتباط.

ننصحك باستخدام SameSite بهذه الطريقة، أي ضبط ملفات تعريف الارتباط التي تؤثر في عرض الموقع الإلكتروني على Lax، وملفات تعريف الارتباط المرتبطة بإجراءات المستخدم على Strict.

يمكنك أيضًا ضبط قيمة SameSite على None للإشارة إلى أنّك تريد إرسال ملف تعريف الارتباط في جميع السياقات. إذا كنت تقدّم خدمة تستخدمها مواقع إلكترونية أخرى، مثل الأدوات أو المحتوى المضمّن أو برامج الشركاء التابعين أو الإعلانات أو تسجيل الدخول على مواقع إلكترونية متعددة، استخدِم None للتأكّد من أنّ نيتك واضحة.

التغييرات على السلوك التلقائي بدون SameSite

تتوفّر السمة SameSite على نطاق واسع، ولكن لم يتم استخدامها على نطاق واسع. في السابق، كان ضبط ملفات تعريف الارتباط بدون SameSite يؤدي تلقائيًا إلى إرسالها في جميع السياقات، ما يعرّض المستخدمين لهجمات تزوير الطلبات عبر المواقع (CSRF) وتسريب المعلومات غير المقصود. لتشجيع المطوّرين على توضيح نيتهم وتوفير تجربة أكثر أمانًا للمستخدمين، يتضمّن اقتراح IETF، Incrementally Better Cookies تغييرَين رئيسيَّين:

• ويتم التعامل مع ملفات تعريف الارتباط التي لا تحتوي على السمة SameSite على أنّها SameSite=Lax.
• يجب أيضًا أن تحدّد ملفات تعريف الارتباط التي تتضمّن SameSite=None السمة Secure، ما يعني أنّها تتطلّب سياقًا آمنًا.

يتوافق كلا التغييرين مع المتصفحات التي نفّذت الإصدار السابق من السمة SameSite بشكل صحيح، بالإضافة إلى المتصفحات التي لا تتوافق مع إصدارات SameSite السابقة. والهدف من ذلك هو تقليل اعتماد المطوّرين على السلوك التلقائي للمتصفّحات من خلال توضيح سلوك ملفات تعريف الارتباط والاستخدام المقصود. على أي برامج لا تتعرّف على SameSite=None تجاهلها.

SameSite=Lax تلقائيًا

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

يجب أن تكون SameSite=None آمنة

عند إنشاء ملفات تعريف ارتباط على مواقع إلكترونية مختلفة باستخدام SameSite=None، يجب أيضًا ضبطها على Secure لكي يقبلها المتصفّح:

Set-Cookie: widget_session=abc123; SameSite=None; Secure

يمكنك اختبار هذا السلوك بدءًا من الإصدار 76 من Chrome من خلال تفعيل about://flags/#cookies-without-same-site-must-be-secure، ومن الإصدار 69 من Firefox من خلال ضبط network.cookie.sameSite.noneRequiresSecure في about:config.

ننصحك أيضًا بتعديل ملفات تعريف الارتباط الحالية إلى Secure في أقرب وقت ممكن. إذا كنت تعتمد على خدمات تقدّم محتوًى تابعًا لجهات خارجية على موقعك الإلكتروني، تأكَّد من أنّ مقدّم الخدمة يعدّل ملفات تعريف الارتباط، وعدِّل أي مقتطفات أو تبعيات على موقعك الإلكتروني للتأكّد من أنّه يستخدم السلوك الجديد.

SameSite وصفات بسكويت

لمزيد من التفاصيل حول تعديل ملفات تعريف الارتباط للتعامل بنجاح مع هذه التغييرات في SameSite=None والاختلافات في سلوك المتصفّح، يُرجى الاطّلاع على المقالة التالية، وصفات ملفات تعريف ارتباط SameSite.

نشكر كل من Lily Chen وMalte Ubl وMike West وRob Dodson وTom Steiner وVivek Sekhar على مساهماتهم وملاحظاتهم.

صورة ملف تعريف الارتباط الرئيسية من Pille-Riin Priske على Unsplash