الموقع الإلكتروني نفسه المخطط

إنّ تعريف "الموقع الإلكتروني نفسه" يجري تطويره ليشمل مخطط عنوان URL، وبالتالي يتم الآن احتساب الروابط بين إصدارَي HTTP وHTTPS من أحد المواقع الإلكترونية كطلبات مواقع إلكترونية متعددة. عليك الترقية إلى بروتوكول HTTPS تلقائيًا لتجنُّب المشاكل حيثما أمكن، أو مواصلة القراءة لمعرفة تفاصيل قيم سمات SameSite المطلوبة.

ستيفن بينغلر

روان ميروود

ملاحظة: هذه المقالة جزء من سلسلة تتناول التغييرات على سمات ملفات تعريف الارتباط SameSite والتي تتضمن:

• فهم ملفات تعريف الارتباط
• شرح ملفات تعريف الارتباط الخاصة بـ SameSite
• وصفات كعك SameSite

يعدِّل Schemeful Same-Site تعريف موقع (ويب) من النطاق القابل للتسجيل فقط إلى المخطط + النطاق القابل للتسجيل. يمكنك الاطّلاع على مزيد من التفاصيل والأمثلة في القسم فهم "الموقع الإلكتروني نفسه" و"المصدر نفسه".

المصطلح الرئيسي: يعني هذا أنّ إصدار HTTP غير الآمن من أحد المواقع الإلكترونية، مثل http://website.example ونسخة HTTPS الآمنة من هذا الموقع الإلكتروني، https://website.example، يُعتبران الآن موقعًا إلكترونيًا متقاطعًا مع بعضهما البعض.

الخبر السار هو أنّه إذا تمت ترقية موقعك الإلكتروني بالكامل إلى بروتوكول HTTPS، لا داعي للقلق بشأن ذلك. لن يحدث أي تغيير.

وإذا لم يسبق لك إجراء ترقية كاملة لموقعك الإلكتروني، يجب أن تكون هذه هي الأولوية. ومع ذلك، إذا كانت هناك حالات سينتقل فيها زوّار موقعك الإلكتروني بين HTTP وHTTPS، سنوضّح في ما يلي بعض هذه السيناريوهات الشائعة وسلوك ملفات تعريف الارتباط SameSite المرتبطة به.

تحذير: تتمثل الخطة طويلة المدى في توفير الدعم لملفات تعريف الارتباط التابعة لجهات خارجية بشكل كامل، واستبدالها ببدائل تحافظ على الخصوصية. إنّ ضبط الحقل SameSite=None; Secure على ملف تعريف ارتباط للسماح بإرساله عبر المخططات يجب اعتباره حلاً مؤقتًا خلال عملية نقل البيانات إلى بروتوكول HTTPS الكامل.

يمكنك تفعيل هذه التغييرات للاختبار في كلٍّ من Chrome وFirefox.

• يُرجى تفعيل "about://flags/#schemeful-same-site" من الإصدار 86 من Chrome. تتبع التقدم على صفحة حالة Chrome.
• من Firefox 79، اضبط network.cookie.sameSite.schemeful على true من خلال about:config. تتبع التقدم عبر مشكلة Bugzilla.

كان أحد الأسباب الرئيسية للتغيير إلى SameSite=Lax كإعداد تلقائي لملفات تعريف الارتباط هو الحماية من تزوير الطلبات من موقع إلكتروني مختلف (CSRF). ومع ذلك، لا تزال حركة بيانات HTTP غير الآمنة تمثل فرصة لمهاجمين الشبكة للتلاعب بملفات تعريف الارتباط التي سيتم استخدامها بعد ذلك على إصدار HTTPS الآمن من الموقع الإلكتروني. يوفر إنشاء هذه الحدود الإضافية عبر المواقع بين المخططات دفاعًا أكبر ضد هذه الهجمات.

السيناريوهات الشائعة بين المخططات

المصطلح الرئيسي: في الأمثلة أدناه التي تتضمّن جميع عناوين URL النطاق نفسه القابل للتسجيل، مثل site.example، ولكن مع أنظمة مختلفة، مثل http://site.example مقارنةً بـ https://site.example، يُشار إلى كل منها باسم نظام مشترك متبادل.

التنقّل

كان التنقّل بين النُسخ المتعدّدة من المواقع الإلكترونية (على سبيل المثال، الربط من http://site.example إلى https://site.example) يسمح سابقًا بإرسال SameSite=Strict ملفات تعريف الارتباط. يتم الآن التعامل مع هذه العملية على أنّها تنقّل بين المواقع الإلكترونية، ما يعني أنّه سيتم حظر ملفات تعريف الارتباط في SameSite=Strict.

التنقّل في جميع الأنظمة من HTTP إلى HTTPS.

	HTTP ← HTTPS	HTTPS ← HTTP
SameSite=Strict	⛔ محظور	⛔ محظور
SameSite=Lax	✓ مسموح به	✓ مسموح به
SameSite=None;Secure	✓ مسموح به	⛔ محظور

جارٍ تحميل الموارد الفرعية

تحذير: تحظر جميع المتصفحات الرئيسية المحتوى المختلَط النشط، مثل النصوص البرمجية أو إطارات iframe. بالإضافة إلى ذلك، تعمل المتصفحات بما في ذلك Chrome وFirefox على ترقية المحتوى المختلَط السلبي أو حظره.

يجب اعتبار أي تغييرات تجريها هنا إصلاحًا مؤقتًا فقط أثناء الترقية إلى بروتوكول HTTPS الكامل.

وتشمل أمثلة الموارد الفرعية الصور وإطارات iframe وطلبات الشبكة التي تم إجراؤها باستخدام XHR أو Fetch.

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

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

صفحة HTTP تتضمن موردًا فرعيًا من عدة أنظمة عبر HTTPS.

	HTTP ← HTTPS	HTTPS ← HTTP
SameSite=Strict	⛔ محظور	⛔ محظور
SameSite=Lax	⛔ محظور	⛔ محظور
SameSite=None;Secure	✓ مسموح به	⛔ محظور

نشر نموذج

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

وكما هو الحال في الموارد الفرعية، إذا كان الطلب ينتقل من مصدر آمن مثل HTTPS إلى سياق غير آمن مثل HTTP، سيتم حظر كل ملفات تعريف الارتباط في هذه الطلبات لأنّ ملفات تعريف الارتباط التابعة لجهات خارجية أو على مواقع إلكترونية متعددة تتطلّب Secure.

تحذير: الحل الأفضل هنا هو التأكّد من اتصال كل من صفحة النموذج والوجهة على اتصال آمن مثل HTTPS. ويُعتبر ذلك أمرًا مهمًا على وجه الخصوص إذا كان المستخدم يُدخِل أي معلومات حساسة في النموذج.

إرسال النموذج من HTTP إلى HTTPS:

	HTTP ← HTTPS	HTTPS ← HTTP
SameSite=Strict	⛔ محظور	⛔ محظور
SameSite=Lax	⛔ محظور	⛔ محظور
SameSite=None;Secure	✓ مسموح به	⛔ محظور

كيف يمكنني اختبار موقعي الإلكتروني؟

تتوفّر أدوات المطوّرين والرسائل على Chrome وFirefox.

واعتبارًا من الإصدار 86 من Chrome، ستشمل علامة التبويب "المشكلة" في "أدوات مطوّري البرامج" مشاكل الموقع الإلكتروني المخطط له. قد تلاحظ تمييز المشاكل التالية المرتبطة بموقعك الإلكتروني.

مشاكل في التنقّل:

• "النقل بالكامل إلى بروتوكول HTTPS لمواصلة إرسال ملفات تعريف الارتباط على طلبات الموقع الإلكتروني نفسه": تحذير بأنّ ملف تعريف الارتباط سيتم حظره في إصدار مستقبلي من Chrome.
• "النقل بالكامل إلى HTTPS ليتم إرسال ملفات تعريف الارتباط على طلبات الموقع الإلكتروني نفسه": تحذير بأنه تم حظر ملف تعريف الارتباط.

مشاكل تحميل الموارد الفرعية:

• "يجب نقل البيانات بالكامل إلى بروتوكول HTTPS لمواصلة إرسال ملفات تعريف الارتباط إلى الموارد الفرعية للموقع الإلكتروني نفسه" أو "النقل بالكامل إلى بروتوكول HTTPS لمواصلة السماح بضبط ملفات تعريف الارتباط بواسطة الموارد الفرعية للموقع الإلكتروني نفسه": تحذيرات من أنّ ملف تعريف الارتباط سيتم حظره في إصدار مستقبلي من Chrome.
• "يجب نقل البيانات بالكامل إلى بروتوكول HTTPS لكي يتم إرسال ملفات تعريف الارتباط إلى الموارد الفرعية للموقع الإلكتروني نفسه" أو "النقل بالكامل إلى بروتوكول HTTPS للسماح بضبط ملفات تعريف الارتباط حسب الموارد الفرعية الخاصة بالموقع الإلكتروني نفسه": تحذيرات بأنّ ملف تعريف الارتباط تم حظره. يمكن أن يظهر التحذير الأخير أيضًا عند نشر نموذج.

يتوفّر مزيد من التفاصيل في المقالة نصائح الاختبار وتصحيح الأخطاء للموقع الإلكتروني نفسه.

بدايةً من الإصدار 79 من Firefox، عند ضبط network.cookie.sameSite.schemeful على true من خلال about:config، ستعرض وحدة التحكّم رسالة بشأن مشاكل schemaful Same-Site. قد تلاحظ ما يلي على موقعك الإلكتروني:

• "سيتم قريبًا التعامل مع ملف تعريف الارتباط cookie_name على أنّه ملف تعريف ارتباط على مواقع إلكترونية متعددة في مقابل http://site.example/ لأنّ المخطط غير متطابق".
• "تمت معالجة ملف تعريف الارتباط cookie_name كملف تعريف ارتباط مواقع إلكترونية متعددة مقابل http://site.example/ لأنّ المخطط لا يتطابق".

الأسئلة الشائعة

موقعي الإلكتروني متاح بالكامل على HTTPS، فلماذا تظهر لي مشاكل في "أدوات مطوري البرامج" في المتصفّح؟

من الممكن أن تظل بعض الروابط والموارد الفرعية تشير إلى عناوين URL غير آمنة.

وإحدى الطرق لإصلاح هذه المشكلة هي استخدام HTTP Exact-Transport-Security (HSTS) والتوجيه includeSubDomain. في حال استخدام HSTS + includeSubDomain، حتى إذا تضمّنت إحدى صفحاتك عن طريق الخطأ رابطًا غير آمن، سيستخدم المتصفّح تلقائيًا الإصدار الآمن بدلاً من ذلك.

ماذا يحدث إذا تعذّر عليّ الترقية إلى HTTPS؟

على الرغم من أننا ننصح بشدة بترقية موقعك الإلكتروني بالكامل إلى بروتوكول HTTPS لحماية المستخدمين، نقترح عليك استشارة المستضيف لمعرفة ما إذا كان بإمكانه توفير هذا الخيار. إذا كنت مضيفًا ذاتيًا، فسيوفر Let's Encrypt عددًا من الأدوات لتثبيت شهادة وإعدادها. يمكنك أيضًا التحقق من نقل موقعك خلف شبكة توصيل للمحتوى أو (CDN) أو أي خادم وكيل آخر يمكنه توفير اتصال HTTPS.

إذا لم ينجح ذلك، جرِّب تخفيف حماية SameSite على ملفات تعريف الارتباط المتأثرة.

• في الحالات التي يتم فيها حظر ملفات تعريف الارتباط SameSite=Strict فقط، يمكنك خفض مستوى الحماية إلى Lax.
• في الحالات التي يتم فيها حظر ملف تعريف الارتباط Strict وLax وإرسال ملفات تعريف الارتباط إلى (أو ضبطها من) عنوان URL آمن، يمكنك خفض مستوى الحماية إلى None.
  • لن ينجح هذا الحل البديل إذا كان عنوان URL الذي ترسل ملفات تعريف الارتباط إليه (أو تضبطه منه) غير آمن. ويرجع ذلك إلى أنّ SameSite=None تتطلّب السمة Secure على ملفات تعريف الارتباط، ما يعني أنّه قد لا يتم إرسال ملفات تعريف الارتباط هذه أو ضبطها عبر اتصال غير آمن. وفي هذه الحالة، لن تتمكّن من الوصول إلى ملف تعريف الارتباط هذا إلى أن تتم ترقية موقعك الإلكتروني إلى بروتوكول HTTPS.
  • وتذكَّر أنّ هذا الإجراء مؤقت، إذ سيتم في النهاية إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية بالكامل.

كيف يؤثر ذلك في ملفات تعريف الارتباط إذا لم أحدّد سمة SameSite؟

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

كيف تتأثر WebSockets؟

ستظل اتصالات WebSocket تعتبر نفس الموقع إذا كانت بنفس مستوى الأمان الموجود في الصفحة.

الموقع نفسه:

• اتصال wss:// من https://
• اتصال ws:// من http://

مواقع مختلفة:

• اتصال wss:// من http://
• اتصال ws:// من https://

صورة من تصوير جوليسا كابديفيلا على UnLaunch