آخر الأخبار
23 آذار (مارس) 2023: تم تعديل المخطط الزمني، ولن يتم إيقاف الميزة نهائيًا إلا في الإصدار 117 من Chrome.
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: طرح الإصدار 90 من Chrome في الإصدار الثابت، مع عرض تحذيرات بشأن الإيقاف النهائي
- حزيران (يونيو) 2021: طرح الإصدار 92 من Chrome في الإصدار التجريبي، مع حظر طلبات الوصول إلى الشبكة الخاصة من سياقات غير آمنة بعد تلقّي ملاحظات من المطوّرين تطلب مزيدًا من الوقت للتأقلم، تم تأجيل الإيقاف النهائي إلى الإصدار 93 من Chrome، وسيترافق معه اختبار الإيقاف النهائي.
- تموز (يوليو) 2021: بعد تلقّي المزيد من الملاحظات من المطوّرين، تم تأجيل إيقاف الميزة نهائيًا والإصدار التمهيدي المصاحب إلى الإصدار 94 من Chrome. بالإضافة إلى ذلك، لم تعُد المواقع الإلكترونية الخاصة تتأثر بعملية الإيقاف النهائي.
- آب (أغسطس) 2021: طرح الإصدار 94 من Chrome في الإصدار التجريبي يمكن لمطوّري الويب بدء الاشتراك في الفترة التجريبية لعملية الإيقاف النهائي.
- أيلول (سبتمبر) 2021: طرح الإصدار 94 من Chrome في الإصدار الثابت من المفترض أن يكون مطوّرو الويب قد اشتركوا في الفترة التجريبية لإيقاف الرموز المميّزة نهائيًا ونشر الرموز المميّزة التجريبية في قناة الإصدار العلني.
- كانون الأول (ديسمبر) 2022: تم إرسال استطلاع الرأي حول الفترة التجريبية لميزة "النشأة" وتلقّي الملاحظات. تم تمديد فترة الإيقاف نهائيًا التجريبية إلى الإصدار 113 من Chrome.
- آذار (مارس) 2023: تم تمديد فترة الإصدار التجريبي لإيقاف الميزة نهائيًا إلى الإصدار 116 من Chrome، ومن المقرر أن تنتهي في الإصدار 117. نحن نعمل على تطوير آلية بديلة تستند إلى الأذونات، ويُتوقّع طرحها في الإصدار الأولي من Chrome 114.
- أيار (مايو) 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 من Chrome
اعتبارًا من الإصدار 94 من Chrome، يُحظر على السياقات العامة غير الآمنة (بشكل عام، المواقع الإلكترونية التي لا يتم عرضها من خلال بروتوكول HTTPS أو من عنوان IP خاص) إرسال طلبات إلى الشبكة الخاصة. كان من المخطَّط سابقًا أن يتم إيقاف هذه الميزة نهائيًا في الإصدار 92 من Chrome، لذا قد تشير رسائل الإيقاف النهائي إلى هذا الموعد النهائي السابق.
سيترافق هذا الإيقاف النهائي بفترة تجريبية للإيقاف النهائي، ما يسمح لمطوّري الويب الذين تستخدم مواقعهم الإلكترونية الميزة التي سيتم إيقافها نهائيًا بمواصلة استخدامها حتى إصدار Chrome 116 من خلال التسجيل للحصول على الرموز المميّزة. يُرجى الاطّلاع أدناه على تعليمات حول كيفية التسجيل في الفترة التجريبية وتفعيلها على موقعك الإلكتروني.
يمكن الاستفادة من سياسات 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 في الإصدار 96 من Chrome (بدأ الإصدار التجريبي من الإصدار العلني) مع إجراءات وقائية لحماية المستخدمين من مشاركة المفاتيح وغيرها من ممارسات الأمان المنخفضة المستوى، بما في ذلك:
- الحد الأقصى لمدة انتهاء صلاحية قصيرة للشهادات المثبّتة
- آلية خاصة بالمتصفّح لإبطال مفاتيح معيّنة تم إساءة استخدامها
لن نطرح قيد السياق الآمن إلا بعد بلوغ إنجازَين على الأقل بعد طرح WebTransport بالكامل. سيتم تمديد الفترة التجريبية لإيقاف الميزة نهائيًا عند الضرورة.
عكس عملية التضمين
لا يتطلّب هذا الحلّ أيّ تحكّم إداري في الشبكة، ويمكن استخدامه عندما لا يكون الخادم المستهدَف قويًا بما يكفي لتشغيل بروتوكول HTTPS.
بدلاً من جلب موارد فرعية خاصة من تطبيق ويب علني، يمكن عرض هيكل أساسي للتطبيق من الخادم الخاص الذي يُجلب بعد ذلك كل موارده الفرعية (مثل النصوص البرمجية أو الصور) من خادم علني، مثل شبكة توصيل المحتوى (CDN). يمكن بعد ذلك لتطبيق الويب الناتج إرسال طلبات إلى الخادم الخاص، لأنّه يُعتبَر من المصدر نفسه. ويمكنه أيضًا إرسال طلبات إلى خوادم أخرى تتضمّن عناوين IP خاصة (ولكن ليس المضيف المحلي)، إلا أنّ ذلك قد يتغيّر على المدى الطويل.
من خلال استضافة إطار عمل فقط على الخادم الخاص، يمكنك تعديل تطبيق الويب من خلال إرسال موارد جديدة إلى الخادم العام، تمامًا كما يمكنك تعديل تطبيق ويب علني. من ناحية أخرى، لا يُعدّ تطبيق الويب الناتج سياقًا آمنًا، لذا لا يمكنه الوصول إلى بعض الميزات الأكثر فعالية على الويب.
الخطط المستقبلية
إنّ حصر طلبات الوصول إلى الشبكة الخاصة بالسياقات الآمنة هو الخطوة الأولى فقط في بدء ميزة "الوصول إلى الشبكة الخاصة". يعمل فريق Chrome على تنفيذ بقية المواصفات في الأشهر المقبلة. يُرجى متابعتنا لمعرفة آخر الأخبار.
حظر الوصول إلى المضيف المحلي من المواقع الإلكترونية الخاصة
لا تؤثر التغييرات في Chrome 94 إلا في المواقع الإلكترونية العلنية التي تصل إلى عناوين IP الخاصة أو localhost. وتصنِّف مواصفات الوصول إلى الشبكة الخاصة أيضًا الطلبات الواردة من المواقع الإلكترونية الخاصة إلى المضيف المحلي على أنّها طلبات مشكلة. وسيتم في النهاية إيقاف هذه الميزة نهائيًا في Chrome. يطرح ذلك مجموعة مختلفة قليلاً من التحديات، لأنّ العديد من المواقع الإلكترونية الخاصة لا تتضمّن أسماء نطاقات، ما يعقد استخدام الرموز المميّزة لإصدار تجريبي من ميزة الإيقاف النهائي.
طلبات التحقّق من CORS
الجزء الثاني من سياسة "الوصول إلى الشبكة الخاصة" هو حظر طلبات الشبكة الخاصة التي يتم إجراؤها من سياقات آمنة باستخدام طلبات التحقّق من CORS. والفكرة هي أنّه حتى إذا تم بدء الطلب من سياق آمن، يُطلب من الخادم المستهدَف تقديم إذن صريح للمُشغِّل. لا يتم إرسال الطلب إلا إذا تم منح الإذن.
بعبارة أخرى، طلب التحقّق من CORS هو طلب OPTIONS HTTP يحمل بعض عناوين
Access-Control-Request-* التي تشير إلى طبيعة
الطلب اللاحق. يمكن للخادم بعد ذلك تحديد ما إذا كان سيمنح إذن وصول دقيقًا أم لا، وذلك من خلال الردّ على 200 OK باستخدام عناوين Access-Control-Allow-*.
يمكنك الاطّلاع على مزيد من التفاصيل حول ذلك في المواصفات.
تقييد عمليات جلب التنقّل
يوقف Chrome نهائيًا طلبات الوصول إلى الموارد الفرعية ويحظرها في نهاية المطاف في الشبكات الخاصة. ولن يؤثّر ذلك في عمليات التنقّل إلى الشبكات الخاصة التي يمكن استخدامها أيضًا في هجمات CSRF.
لا تفرِّق مواصفات الوصول إلى الشبكة الخاصة بين النوعَين من عمليات الجلب، والتي ستخضع في النهاية لقيود مماثلة.
صورة الغلاف مقدمة من ماركوس سبيسكي على Unsplash