آخر الأخبار
23 آذار (مارس) 2023: تم تعديل المخطط الزمني، ولن يتم إيقافه نهائيًا حتى إصدار Chrome 117.
19 كانون الثاني (يناير) 2023: تم تعديل المخطط الزمني، ولن يتم إيقاف الميزة نهائيًا حتى الإصدار 114 من Chrome.
12 آب (أغسطس) 2022: تم تعديل المخطط الزمني، ولن يتم إيقاف الميزة نهائيًا حتى الإصدار 109 من Chrome.
10 شباط (فبراير) 2022: تم نشر مقالة معدَّلة على الرابط الوصول إلى الشبكة الخاصة: تقديم ميزة "الرحلات التجريبية".
25 آب (أغسطس) 2021: تم تعديل إعلان المخطط الزمني وتقديم فترة تجريبية لإيقاف الميزة نهائيًا.
سيتوقف Chrome نهائيًا عن السماح بالوصول إلى نقاط نهاية الشبكة الخاصة من المواقع الإلكترونية غير الآمنة كجزء من مواصفات الوصول إلى الشبكة الخاصة. والهدف من ذلك هو حماية المستخدمين من هجمات تزوير الطلبات من مواقع إلكترونية متعددة (CSRF) تستهدف أجهزة التوجيه والأجهزة الأخرى على الشبكات الخاصة. وأثّرت هذه الهجمات على مئات الآلاف من المستخدمين، مما أتاح للمهاجمين إعادة توجيههم إلى خوادم ضارة.
سيقدِّم Chrome التغييرات التالية:
- حظر الطلبات إلى الشبكات الخاصة من المواقع الإلكترونية العامة غير الآمنة اعتبارًا من Chrome 94
- نقدّم لك فترة تجريبية للإيقاف النهائي ستنتهي في Chrome
- وسيسمح هذا للمطوّرين بطلب تمديد الوقت للمصادر التي تم اختيارها، ولن يتأثر خلال الفترة التجريبية للإيقاف النهائي.
- سنقدّم سياسة Chrome التي ستسمح لعمليات نشر Chrome المُدارة بتجاوز إيقاف الميزة نهائيًا. متاح في الإصدار 92 من Chrome.
إذا كنت بحاجة إلى مزيد من الوقت للتخفيف من تأثير الإيقاف النهائي، سجِّل في مرحلة اختبار الإيقاف النهائي.
إذا كان لديك تحكّم إداري في المستخدمين، يمكنك إعادة تفعيل الميزة باستخدام سياسات Chrome.
للحدّ من تأثير القيود الجديدة، استخدِم إحدى الستراتيجيتَين التاليتَين:
- عليك ترقية موقعك الإلكتروني إلى HTTPS، مع الخادم المستهدف إذا لزم الأمر.
- عليك ترقية موقعك الإلكتروني إلى HTTPS واستخدام WebTransport.
- عكس علاقة التضمين
المخطط الزمني
- تشرين الثاني (نوفمبر) 2020: طلب ملاحظات حول التغييرات القادمة
- آذار (مارس) 2021: بعد مراجعة الملاحظات والتواصل مع صنّاع المحتوى، أعلنّا عن التغييرات القادمة. تمت إعادة تسمية المواصفة من CORS-RFC1918 إلى "الوصول إلى الشبكة الخاصة".
- نيسان (أبريل) 2021: طرح Chrome 90 كإصدار ثابت يعرض تحذيرات الإيقاف نهائيًا
- حزيران (يونيو) 2021: طرح الإصدار 92 من Chrome في الإصدار التجريبي، مع حظر طلبات الوصول إلى الشبكة الخاصة من سياقات غير آمنة بعد تلقّي ملاحظات من مطوّري البرامج يطلبون مزيدًا من الوقت لإجراء التعديلات، تم تأجيل عملية الإيقاف إلى الإصدار 93 من Chrome، إلى جانب تجربة للإيقاف النهائي.
- تموز (يوليو) 2021: بعد تلقّي المزيد من الملاحظات من المطوّرين، تم تأجيل إيقاف الميزة نهائيًا والإصدار التمهيدي المصاحب إلى الإصدار 94 من Chrome. بالإضافة إلى ذلك، لم تعد المواقع الإلكترونية الخاصة تتأثر بالإيقاف النهائي.
- آب (أغسطس) 2021: طرح Chrome 94 كإصدار تجريبي يمكن لمطوّري الويب بدء الاشتراك في الفترة التجريبية لعملية الإيقاف النهائي.
- أيلول (سبتمبر) 2021: طرح Chrome 94 في القناة الثابتة من المفترض أن يكون مطوّرو الويب قد اشتركوا في الفترة التجريبية لإيقاف الرموز المميّزة نهائيًا ونشر الرموز المميّزة التجريبية في قناة الإصدار العلني.
- كانون الأول (ديسمبر) 2022: تم إرسال استطلاع الرأي حول الفترة التجريبية لميزة "الأسعار المتغيرة حسب الوقت" وتلقّي الملاحظات. تم تمديد فترة الإيقاف نهائيًا التجريبية إلى الإصدار 113 من Chrome.
- آذار (مارس) 2023: تم تمديد فترة التجربة الخاصة بإيقاف الميزة نهائيًا إلى الإصدار 116 من Chrome، ومن المقرر أن تنتهي في الإصدار 117. نحن نعمل على تطوير آلية بديلة تستند إلى الأذونات، ويستهدف الإصدار الأولي منها الإصدار 114 من Chrome.
- أيار (مايو) 2023 (تاريخ مبدئي): طرح الآلية المستندة إلى الأذونات في الإصدار 114 من Chrome ويمكن للمواقع الإلكترونية استخدامها للخروج من الفترة التجريبية للإيقاف النهائي.
- أيلول (سبتمبر) 2023: طرح الإصدار 117 من Chrome في الإصدار الثابت، ما يُنهي فترة التجربة الخاصة بإيقاف الميزة نهائيًا يحظر Chrome جميع طلبات الشبكات الخاصة من السياقات العامة غير الآمنة.
ما هو الوصول إلى الشبكة الخاصة؟
الوصول إلى الشبكة الخاصة (المعروف سابقًا باسم CORS-RFC1918) يحدّ من قدرة المواقع الإلكترونية على إرسال الطلبات إلى الخوادم على الشبكات الخاصة. وهو لا يسمح بهذه الطلبات إلا من السياقات الآمنة. وتوسّع المواصفة أيضًا نطاق بروتوكول مشاركة الموارد المتعددة المصادر (CORS) لكي تطلب المواقع الإلكترونية الآن صراحةً منح الإذن من الخوادم على الشبكات الخاصة قبل السماح لها بإرسال طلبات عشوائية.
طلبات الشبكة الخاصة هي الطلبات التي يكون عنوان IP للخادم المستهدَف فيها أكثر
خصوصية من عنوان IP الذي تم جلب مُشغِّل الطلب منه. على سبيل المثال،
طلب من موقع إلكتروني متاح للجميع (https://example.com) إلى موقع إلكتروني خاص
(http://router.local)، أو طلب من موقع إلكتروني خاص إلى المضيف المحلي
اطّلِع على مزيد من المعلومات على نطلب ملاحظاتك بشأن المشاكل المتعلقة بمشاركة موارد عناوين URL التابعة للنطاق نفسه (CORS) على الشبكات الخاصة (RFC1918).
ما هي إعادة ميزة تم إيقافها نهائيًا؟
مراحل إعادة الميزة التي تم إيقافها نهائيًا (المعروفة سابقًا باسم مراحل إعادة التقييم) هي شكل من أشكال مراحل التقييم تُستخدَم لتسهيل إيقاف ميزات الويب نهائيًا. تتيح تجارب الإيقاف النهائي لمتصفِّح Chrome إيقاف بعض ميزات الويب نهائيًا ومنع المواقع الإلكترونية من إنشاء اعتمادات جديدة عليها، مع منح المواقع الإلكترونية التابعة الحالية وقتًا إضافيًا لإيقاف تلك الميزات.
خلال فترة تجريبية لإيقاف الميزات نهائيًا، لا تتوفّر الميزات التي سيتم إيقافها نهائيًا تلقائيًا في كل المواقع الإلكترونية. على المطوّرين الذين لا يزالون بحاجة إلى استخدام الميزات المتأثرة الاشتراك في الفترة التجريبية لإيقاف الميزات نهائيًا والحصول على الرموز المميّزة لمواقع الويب المحدّدة، ثم تعديل مواقعهم الإلكترونية لعرض هذه الرموز المميّزة في رؤوس HTTP أو العلامات الوصفية (باستثناء هذه الحالة). إذا كان الموقع الإلكتروني يعرض علامات مميّزة صالحة تتطابق مع مصدرها، سيسمح Chrome باستخدام الميزة المتوقّفة نهائيًا لفترة محدودة من الزمن.
للمزيد من المعلومات، يُرجى الاطّلاع على بدء استخدام مراحل التجربة والتقييم من Chrome ودليل مطوّري الويب حول تجارب المصادر للحصول على التعليمات.
التغييرات في Chrome
Chrome 94
اعتبارًا من الإصدار 94 من Chrome، يُحظر على السياقات العامة غير الآمنة (بشكل عام، المواقع الإلكترونية التي لا يتم عرضها من خلال بروتوكول HTTPS أو من عنوان IP خاص) إرسال طلبات إلى الشبكة الخاصة. كان من المخطّط سابقًا أن يتم إيقاف هذه الميزة نهائيًا في الإصدار 92 من Chrome، لذا قد تشير رسائل الإيقاف النهائي إلى هذا الموعد النهائي السابق.
سيترافق هذا الإيقاف النهائي بفترة تجريبية للإيقاف النهائي، ما يسمح لمطوّري الويب الذين تستخدم مواقعهم الإلكترونية الميزة التي سيتم إيقافها نهائيًا بمواصلة استخدامها حتى إصدار Chrome 116 من خلال التسجيل للحصول على الرموز المميّزة. يُرجى الاطّلاع أدناه على تعليمات حول كيفية التسجيل في الفترة التجريبية وتفعيلها على موقعك الإلكتروني.
يمكن الاستفادة من سياسات Chrome لإيقاف الإيقاف النهائي نهائيًا أو بشكل مؤقت في مصادر معيّنة. ويسمح ذلك لعمليات تثبيت Chrome المُدارة، على سبيل المثال، عمليات تثبيت Chrome في إعدادات الشركة بتجنُّب الأعطال.
Chrome 117
تنتهي الفترة التجريبية للإيقاف النهائي. يجب نقل جميع المواقع الإلكترونية من الميزة التي سيتم إيقافها نهائيًا، أو ضبط سياسات المستخدمين لمواصلة تفعيل الميزة.
إجراءات المطوّرين المقترَحة
من المرجّح أن تكون الخطوة الأولى للمواقع الإلكترونية المتأثّرة هي شراء بعض الوقت إلى أن يتم طرح حلّ مناسب، إما من خلال التسجيل في فترة الطرح التجريبي للميزة، أو من خلال استخدام السياسات. بعد ذلك، يختلف الإجراء المقترَح حسب ظروف كل موقع إلكتروني متأثر.
التسجيل في الفترة التجريبية لاستخدام ميزة تم إيقافها نهائيًا
- انقر على تسجيل في الإصدار التجريبي من ميزة "الوصول إلى الشبكة الخاصة من مصادر السياقات غير الآمنة" للحصول على رمز مميّز للإصدار التجريبي للمصدر المشارِك.
- أضِف السمة
Origin-Trial: $tokenالخاصة بالمصدر إلى عنوان الردّ. يجب ضبط عنوان الاستجابة هذا على ردود الموارد والتنقل الأساسي فقط عندما يستخدم المستند الناتج الميزة المتوقّفة نهائيًا. لا فائدة من إرفاق هذا العنوان بموارد فرعية الاستجابات (على الرغم من أنّه لا يضرّ).
وبما أنّه يجب تفعيل هذه الفترة التجريبية أو إيقافها قبل السماح للمستند بمحاولة
تقديم أي طلبات، لا يمكن تفعيلها من خلال علامة <meta>. ولا تتم معالجة هذه العلامات إلا من محتوى الاستجابة بعد أن يتم توجيه طلبات الموارد الفرعية. يشكّل ذلك تحديًا للمواقع الإلكترونية التي لا تتحكّم في عناوين
الاستجابة، مثل المواقع الإلكترونية الثابتة على github.io التي تعرضها جهة خارجية.
لمزيد من التفاصيل، يُرجى الاطّلاع على دليل المطوِّر على الويب لمراحل التجربة والتقييم.
تفعيل السياسات
إذا كان لديك إذن تحكّم إداري في المستخدمين، يمكنك إعادة تفعيل الميزة المنتهية الصلاحية باستخدام أيّ من السياستَين التاليتَين:
للاطّلاع على مزيد من التفاصيل حول إدارة السياسات للمستخدمين، يُرجى الاطّلاع على مقالة مركز المساعدة هذه.
الوصول إلى المضيف المحلي
إذا كان موقعك الإلكتروني يحتاج إلى إصدار طلبات إلى المضيف المحلي، ما عليك سوى ترقية موقعك الإلكتروني إلى HTTPS.
لا يحظر المحتوى المختلط الطلبات التي تستهدف http://localhost (أو http://127.*.*.* أو http://[::1])،
حتى إذا كان صادرة من سياقات آمنة.
يُرجى العلم أنّ محرّك WebKit والمتصفّحات المستندة إليه (على رأسها Safari) يخالفان مواصفات المحتوى المختلط في W3C هنا ويحظران هذه الطلبات باعتبارها محتوى مختلطًا. وهي لا تستخدم ميزة "الوصول إلى الشبكة الخاصة"، وبالتالي قد ترغب المواقع الإلكترونية في إعادة توجيه العملاء الذين يستخدمون مثل هذه المتصفحات إلى نسخة HTTP بنص عادي من الموقع الإلكتروني، والتي ستظلّ مسموحًا بها من خلال هذه المتصفحات بتقديم طلبات إلى المضيف المحلي.
الوصول إلى عناوين IP الخاصة
إذا كان موقعك الإلكتروني بحاجة إلى إرسال طلبات إلى خادم مستهدَف على عنوان IP خاص، لن يؤدي ترقية موقع المشغِّل الإلكتروني إلى HTTPS إلى حلّ المشكلة. يمنع "المحتوى المختلط" السياقات الآمنة من إرسال طلبات عبر HTTP النصي العادي، وبالتالي سيظلّ الموقع الإلكتروني الآمن حديثًا غير قادر على إرسال الطلبات. هناك بضع طرق لحلّ هذه المشكلة:
- ترقية كلا الطرفَين إلى HTTPS
- استخدِم WebTransport للاتصال الآمن بالخادم المستهدَف.
- قم بعكس علاقة التضمين.
ترقية الطرفَين إلى بروتوكول HTTPS
يتطلّب هذا الحلّ التحكّم في عملية حلّ أسماء النطاقات للمستخدمين، كما قد يكون الحال في سياقات الشبكة الداخلية، أو إذا كان المستخدمون يحصلون على عناوين خوادم أسمائهم من خادم DHCP تحت سيطرتك. ويتطلب ذلك أيضًا امتلاك اسم نطاق عام.
تكمن المشكلة الرئيسية في عرض المواقع الإلكترونية الخاصة عبر HTTPS في أنّ المراجع المصدقة للبنية التحتية للمفاتيح العامة (PKI CA) لا توفّر سوى شهادات بروتوكول أمان طبقة النقل (TLS) للمواقع الإلكترونية التي تحمل أسماء نطاقات عامة. لحلّ هذه المشكلة، اتّبِع الخطوات التالية:
- سجِّل اسم نطاق علنيًا (مثل
intranet.example) وانشر سجلّات نظام أسماء النطاقات التي تشير إلى اسم النطاق هذا لخادم علني من اختيارك. - الحصول على شهادة بروتوكول أمان طبقة النقل (TLS) لموقع
intranet.example - داخل شبكتك الخاصة، اضبط نظام أسماء النطاقات للتعامل بشكل نهائي مع
intranet.exampleلتحديد عنوان IP الخاص بالخادم المستهدَف. - اضبط الخادم الخاص لاستخدام شهادة بروتوكول أمان طبقة النقل (TLS) لحساب
intranet.example. يتيح ذلك للمستخدمين الوصول إلى الخادم الخاص على العنوانhttps://intranet.example.
يمكنك بعد ذلك ترقية الموقع الإلكتروني الذي يُنشئ الطلبات إلى HTTPS و مواصلة إرسال الطلبات كالمعتاد.
هذا الحلّ ملائم للمستقبل ويقلل من الثقة التي تمنحُها لشبكتك، ويؤدي إلى توسيع نطاق استخدام التشفير التام بين الأطراف في شبكتك الخاصة.
WebTransport
لا يتطلّب هذا الحل التحكّم في عملية تحديد نظام أسماء النطاقات للمستخدمين. ويتطلب ذلك تشغيل خادم WebTransport بحدّ أدنى من الوظائف (خادم HTTP/3 مع بعض التعديلات) على الخادم المستهدَف.
يمكنك تجاوز عدم توفُّر شهادة صالحة لبروتوكول أمان طبقة النقل (TLS) موقَّعة من مرجع تصديق موثوق به باستخدام WebTransport وآلية تثبيت الشهادات. يتيح ذلك إنشاء اتصالات آمنة بالأجهزة الخاصة التي قد تحتوي على شهادة موقَّعة ذاتيًا على سبيل المثال. تتيح اتصالات WebTransport نقل البيانات ثنائي الاتجاه، ولكنها لا تسمح بطلبات الاسترجاع. يمكنك الجمع بين هذين الأسلوبين مع عامل خدمة للتوسّط بشكل شفاف لطلبات HTTP عبر الربط، من وجهة نظر تطبيق الويب. من جهة الخادم، يمكن لطبقة الترجمة المقابلة تحويل رسائل WebTransport إلى طلبات HTTP.
ونحن ندرك أنّ ذلك يمثّل قدرًا معقولاً من العمل، ولكن يجب أن يكون أسهل بكثير من الاستفادة من WebRTC، ونأمل أيضًا أن يتم تطبيق جزء من الاستثمار اللازم كمكتبات قابلة لإعادة الاستخدام. ونرى أيضًا أنّه من المفيد جدًا إجراء ذلك، لأنّه من المحتمل أن تفقد السياقات غير الآمنة إمكانية الوصول إلى المزيد والمزيد من ميزات منصة الويب مع اتجاه المنصة إلى تشجيع استخدام بروتوكول HTTPS بطرق أكثر فعالية بمرور الوقت. وبغض النظر عن الوصول إلى الشبكة الخاصة، من المحتمل أن يكون هذا استثمارًا حكيمًا على أي حال.
نتوقّع أن يتم شحن WebTransport عبر HTTP/3 في الإصدار Chrome 96 (لقد بدأ فترة تجريبية للمصدر) مع إجراءات التخفيف للحماية من مشاركة المفتاح ومن ممارسات الأمان الأخرى دون المستوى المطلوب، بما في ذلك:
- الحد الأقصى لمدة انتهاء صلاحية قصيرة للشهادات المثبَّتة
- يشير ذلك المصطلح إلى آلية خاصة بالمتصفّح لإلغاء مفاتيح معيّنة تم إساءة استخدامها.
لن نطرح قيد السياق الآمن إلا بعد بلوغ إنجازَين على الأقل بعد طرح WebTransport بالكامل. سيتم تمديد فترة الإيقاف التجريبي إذا لزم الأمر.
عكس عملية التضمين
لا يتطلّب هذا الحلّ أيّ تحكّم إداري في الشبكة، ويمكن استخدامه عندما لا يكون الخادم المستهدَف قويًا بما يكفي لتشغيل بروتوكول HTTPS.
وبدلاً من جلب موارد فرعية خاصة من تطبيق ويب متاح للجميع، يمكن عرض بنية التطبيق من الخادم الخاص، الذي يجلب بعد ذلك جميع موارده الفرعية (مثل النصوص البرمجية أو الصور) من خادم عام، مثل شبكة توصيل المحتوى (CDN). يمكن بعد ذلك لتطبيق الويب الناتج إرسال طلبات إلى الخادم الخاص، لأنّه يُعتبَر من المصدر نفسه. ويمكنه أيضًا تقديم طلبات إلى خوادم أخرى باستخدام عناوين IP خاصة (وليس المضيف المحلي)، على الرغم من أن هذا قد يتغير على المدى الطويل.
من خلال استضافة إطار عمل فقط على الخادم الخاص، يمكنك تعديل تطبيق الويب من خلال إرسال موارد جديدة إلى الخادم العام، تمامًا كما يمكنك تعديل تطبيق ويب علني. من ناحية أخرى، لا يُعدّ تطبيق الويب الناتج سياقًا آمنًا، لذا لا يمكنه الوصول إلى بعض الميزات الأكثر فعالية على الويب.
الخطط المستقبلية
إنّ حصر طلبات الشبكة الخاصة بالسياقات الآمنة هو الخطوة الأولى فقط في بدء ميزة "الوصول إلى الشبكة الخاصة". يعمل فريق Chrome على تنفيذ بقية المواصفات في الأشهر المقبلة. يُرجى متابعتنا لمعرفة آخر الأخبار.
حظر وصول المضيف المحلي من المواقع الإلكترونية الخاصة
لا تؤثر التغييرات في Chrome 94 إلا في المواقع الإلكترونية العلنية التي تصل إلى عناوين IP الخاصة أو الخادم المحلي. وتصنِّف مواصفات الوصول إلى الشبكة الخاصة أيضًا الطلبات الواردة من المواقع الإلكترونية الخاصة إلى المضيف المحلي على أنّها طلبات مشكلة. وسيتم في النهاية إيقاف هذين المقياسين نهائيًا في Chrome. يطرح ذلك مجموعة مختلفة قليلاً من التحديات، لأنّ العديد من المواقع الإلكترونية الخاصة لا تحتوي على أسماء نطاقات، ما يعقد استخدام الرموز المميّزة لإصدار تجريبي من ميزة الإيقاف النهائي.
طلبات الطلب الأوّلي لـ CORS
الجزء الثاني من سياسة "الوصول إلى الشبكة الخاصة" هو حظر طلبات الشبكة الخاصة التي يتم إجراؤها من سياقات آمنة باستخدام طلبات التحقّق من CORS. والفكرة هي أنّه حتى إذا تم بدء الطلب من سياق آمن، يُطلب من الخادم المستهدَف تقديم إذن صريح للمُشغِّل. لا يتم إرسال الطلب إلا إذا تم منح الإذن.
باختصار، طلب طلب CORS المبدئي هو طلب HTTP OPTIONS يتضمّن بعض عناوين Access-Control-Request-* التي تشير إلى طبيعة الطلب اللاحق. يمكن للخادم بعد ذلك تحديد ما إذا كان سيمنح إذن وصول دقيقًا أم لا، وذلك من خلال الردّ على 200 OK باستخدام عناوين Access-Control-Allow-*.
يمكنك الاطّلاع على مزيد من التفاصيل حول ذلك في المواصفات.
فرض قيود على عمليات استرجاع البيانات أثناء التنقّل
سيُوقف Chrome نهائيًا طلبات الموارد الفرعية للشبكات الخاصة ويحظرها في النهاية. ولن يؤثّر ذلك في عمليات التنقّل إلى الشبكات الخاصة التي يمكن استخدامها أيضًا في هجمات CSRF.
لا تفرِّق مواصفات الوصول إلى الشبكة الخاصة بين النوعَين من عمليات الجلب، اللذَين سيخضعَان في النهاية لقيود مماثلة.
صورة الغلاف مقدمة من ماركوس سبيسكي على Unsplash