يتم تطوير تعريف "الموقع الإلكتروني نفسه" ليشمل مخطّط عنوان URL، لذا يتم الآن احتساب الروابط بين إصدارَي HTTP وHTTPS من الموقع الإلكتروني كطلبات واردة من عدة مواقع إلكترونية. يمكنك الترقية إلى HTTPS تلقائيًا لتجنُّب المشاكل متى أمكن، أو يمكنك الاطّلاع على التفاصيل حول قيم سمة SameSite المطلوبة.
تعمل ميزة Schemeful Same-Site على تعديل تعريف الموقع الإلكتروني (على الويب) من مجرد النطاق القابل للتسجيل إلى المخطط + النطاق القابل للتسجيل. يمكنك العثور على مزيد من التفاصيل والأمثلة في مقالة فهم "الموقع الإلكتروني نفسه" و "المصدر نفسه".
الخبر السار هو أنّه إذا سبق أن تمت ترقية موقعك الإلكتروني بالكامل إلى HTTPS، لن تحتاج إلى القلق بشأن أي شيء. لن يحدث أي تغيير لك.
إذا لم تكن قد أجريت ترقية كاملة لموقعك الإلكتروني حتى الآن، يجب أن يكون هذا هو الإجراء المُهمّ.
ومع ذلك، إذا كانت هناك حالات ينتقل فيها زوّار موقعك الإلكتروني بين HTTP و
HTTPS، سيتم توضيح بعض هذه السيناريوهات الشائعة وSameSite
سلوك ملف تعريف الارتباط
المرتبط بها لاحقًا في هذه المقالة.
يمكنك تفعيل هذه التغييرات للاختبار في كلّ من Chrome وFirefox.
- من الإصدار 86 من Chrome، فعِّل
about://flags/#schemeful-same-site
. يمكنك تتبُّع مستوى التقدّم في صفحة حالة Chrome. - من Firefox 79، اضبط
network.cookie.sameSite.schemeful
علىtrue
من خلالabout:config
. يمكنك تتبُّع مستوى التقدّم باستخدام مشكلة Bugzilla.
كان أحد الأسباب الرئيسية للتغيير إلى SameSite=Lax
كقيمة تلقائية لملفّات تعريف الارتباط هو الحماية من التزوير في الطلبات من مواقع إلكترونية متعددة (CSRF). ومع ذلك، تظل زيارات HTTP غير الآمنة توفّر فرصة لمهاجمي الشبكة للتلاعب بملفات تعريف الارتباط التي سيتم استخدامها بعد ذلك في الإصدار الآمن من HTTPS للموقع الإلكتروني. يوفر إنشاء هذه الحدود الإضافية على مستوى الموقع الإلكتروني بين المخططات
مزيدًا من الحماية ضد هذه الهجمات.
السيناريوهات الشائعة على مستوى جميع المخططات
التنقّل
في السابق، كان الانتقال بين إصدارات الموقع الإلكتروني التي تستخدم مخططات مختلفة (على سبيل المثال، الربط من
http://site.example إلى https://site.example) يسمح بإرسال ملفات تعريف ارتباط
SameSite=Strict
. ويتم الآن التعامل مع هذا الإجراء على أنّه عملية تنقّل على مستوى عدّة مواقع إلكترونية، ما يعني أنّه سيتم حظر SameSite=Strict
ملفّات تعريف الارتباط.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ محظور | ⛔ محظور |
SameSite=Lax
|
✓ مسموح به | ✓ مسموح به |
SameSite=None;Secure
|
✓ مسموح به | ⛔ محظور |
تحميل الموارد الفرعية
يجب اعتبار أي تغييرات تجريها هنا مجرد حلّ مؤقت أثناء عملك على الترقية إلى HTTPS بالكامل.
تشمل أمثلة الموارد الفرعية الصور وإطارات iframe وطلبات الشبكة التي يتم إجراؤها باستخدام XHR أو Fetch.
في السابق، كان تحميل مورد فرعي على مستوى نطاقات متعددة في صفحة يسمح بإرسال ملفات تعريف الارتباط
SameSite=Strict
أو SameSite=Lax
أو ضبطها. ويتم الآن التعامل مع هذا المورد الفرعي بالطريقة نفسها التي يتم التعامل بها مع أي مورد فرعي آخر تابع لجهة خارجية أو على مواقع إلكترونية مختلفة، ما يعني أنّه سيتم حظر أي ملفات تعريف ارتباط SameSite=Strict
أو SameSite=Lax
.
بالإضافة إلى ذلك، حتى إذا كان المتصفّح يسمح بتحميل موارد من مخططات غير آمنة
على صفحة آمنة، سيتم حظر جميع ملفات تعريف الارتباط في هذه الطلبات لأنّ
ملفات تعريف الارتباط التابعة لجهات خارجية أو على مواقع إلكترونية مختلفة تتطلّب Secure
.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ محظور | ⛔ محظور |
SameSite=Lax
|
⛔ محظور | ⛔ محظور |
SameSite=None;Secure
|
✓ مسموح به | ⛔ محظور |
إرسال نموذج
في السابق، كان نشر المحتوى بين إصدارات الموقع الإلكتروني على نطاقات مختلفة يسمح بتمكين إرسال ملفّات تعريف الارتباط التي تم ضبطها باستخدام SameSite=Lax
أو SameSite=Strict
. ويتم الآن التعامل مع هذا الطلب
على أنّه طلب POST من موقع إلكتروني مختلف، ولا يمكن إرسال سوى ملفات تعريف الارتباط SameSite=None
. قد تواجه
هذا السيناريو على المواقع الإلكترونية التي تعرض الإصدار غير الآمن تلقائيًا،
ولكنها تُجري ترقية للمستخدمين إلى الإصدار الآمن عند إرسال نموذج تسجيل الدخول أو
نموذج الدفع.
كما هو الحال مع الموارد الفرعية، إذا كان الطلب واردًا من سياق آمن (مثل HTTPS) إلى
سياق غير آمن (مثل HTTP)، سيتم حظر جميع ملفات تعريف الارتباط في هذه الطلبات
لأنّ ملفات تعريف الارتباط التابعة لجهات خارجية أو على مواقع إلكترونية مختلفة تتطلّب Secure
.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ محظور | ⛔ محظور |
SameSite=Lax
|
⛔ محظور | ⛔ محظور |
SameSite=None;Secure
|
✓ مسموح به | ⛔ محظور |
كيف يمكنني اختبار موقعي الإلكتروني؟
تتوفّر أدوات المطوّرين والرسائل في Chrome وFirefox.
اعتبارًا من الإصدار 86 من Chrome، ستتضمّن علامة التبويب "المشاكل" في أدوات مطوري البرامج مشاكل ميزة SameSite المتعددة المخطّطات. قد تظهر لك المشاكل التالية مميّزة لموقعك الإلكتروني.
مشاكل التنقّل:
- "يجب نقل البيانات بالكامل إلى HTTPS لمواصلة إرسال ملفات تعريف الارتباط في طلبات الموقع الإلكتروني نفسه": تحذير بأنّه سيتم حظر ملف تعريف الارتباط في إصدار مستقبلي من Chrome
- "يجب نقل البيانات بالكامل إلى HTTPS لإرسال ملفات تعريف الارتباط في طلبات الموقع الإلكتروني نفسه": تحذير بأنّه تم حظر ملف تعريف الارتباط
مشاكل في تحميل الموارد الفرعية:
- "الانتقال بالكامل إلى HTTPS لمواصلة إرسال ملفات تعريف الارتباط إلى موارد فرعية في الموقع الإلكتروني نفسه" أو "الانتقال بالكامل إلى HTTPS لمواصلة السماح لموارد فرعية في الموقع الإلكتروني نفسه بضبط ملفات تعريف الارتباط": تحذيرات بأنّه سيتم حظر ملف تعريف الارتباط في إصدار مستقبلي من Chrome
- "الانتقال بالكامل إلى HTTPS لإرسال ملفات تعريف الارتباط إلى الموارد الفرعية للموقع الإلكتروني نفسه" أو "الانتقال بالكامل إلى HTTPS للسماح بملفات تعريف الارتباط التي يتم ضبطها من خلال موارد الفرعية للموقع الإلكتروني نفسه": تحذيرات بأنّه تم حظر ملف تعريف الارتباط يمكن أن يظهر التحذير الأخير أيضًا عند إرسال نموذج.
تتوفّر مزيد من التفاصيل في نصائح حول اختبار Schemeful Same-Site وتحديد الأخطاء وإصلاحها.
اعتبارًا من الإصدار 79 من Firefox، عند ضبط network.cookie.sameSite.schemeful
على true
من خلال
about:config
، ستعرِض وحدة التحكّم رسالة بشأن المشاكل المتعلّقة بميزة "الموقع نفسه" في مخطّط البيانات.
قد تظهر لك العناصر التالية على موقعك الإلكتروني:
- "سيتم قريبًا التعامل مع ملف تعريف الارتباط
cookie_name
على أنّه ملف تعريف ارتباط على مستوى مواقع إلكترونية متعددة فيhttp://site.example/
لأنّ المخطط لا يتطابق." - "تم التعامل مع ملف تعريف الارتباط
cookie_name
على أنّه ملف تعريف ارتباط على مستوى مواقع إلكترونية متعددة فيhttp://site.example/
لأنّ المخطط لا يتطابق."
الأسئلة الشائعة
موقعي الإلكتروني متاح بالكامل على HTTPS، فلماذا تظهر لي مشاكل في "أدوات المطوّر" في المتصفّح؟
من المحتمل أنّ بعض الروابط والموارد الفرعية لا تزال تشير إلى عناوين URL غير آمنة.
تتمثل إحدى طرق حلّ هذه المشكلة في استخدام HTTP
Strict-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. - يُرجى العِلم أنّ هذا الإجراء مؤقت فقط، لأنّه في نهاية المطاف سيتم التوقف نهائيًا عن استخدام ملفات تعريف الارتباط التابعة لجهات خارجية.
- لن ينجح هذا الحلّ البديل إذا كان عنوان URL الذي تُرسِل إليه ملفات تعريف الارتباط (أو
يتم ضبطها منه) غير آمن. ويعود السبب في ذلك إلى أنّ
كيف يؤثر ذلك في ملفات تعريف الارتباط إذا لم أحدّد سمة SameSite
؟
يتم التعامل مع ملفات تعريف الارتباط التي لا تحتوي على سمة SameSite
كما لو كانت قد حدّدت
SameSite=Lax
، وينطبق السلوك نفسه على مستوى جميع المخططات على ملفات تعريف الارتباط هذه
أيضًا. يُرجى العِلم أنّ الاستثناء المؤقت للطرق غير الآمنة لا يزال ساريًا. يُرجى الاطّلاع على الإجراءات التي تم اتّخاذها للتخفيف من مخاطر هجمات Lax + POST في SameSite
FAQ حول Chromium لمزيد من المعلومات.
ما مدى تأثُّر بروتوكول WebSocket؟
سيظلّ الاتصال عبر WebSocket مُصنَّفًا على أنّه من الموقع الإلكتروني نفسه إذا كان يتمتع بالمستوى نفسه من الأمان مثل الصفحة.
الموقع نفسه:
- اتصال
wss://
منhttps://
- اتصال
ws://
منhttp://
على مستوى المواقع الإلكترونية المختلفة:
- اتصال
wss://
منhttp://
- اتصال
ws://
منhttps://
صورة من تصوير جوليسا كابديفيا على Unsplash