خبر جديد حول ميزة "الوصول إلى الشبكة الخاصة": إطلاق فترة تجريبية للإيقاف النهائي

Titouan Rigoudy
Titouan Rigoudy
Yifan Luo
Yifan Luo
GitHub

آخر الأخبار

  • 23 آذار (مارس) 2023: تم تعديل المخطّط الزمني، ولن يحدث الإيقاف النهائي إلا بعد الإصدار 117 من متصفّح Chrome.

  • 19 كانون الثاني (يناير) 2023: تم تعديل المخطّط الزمني ولن يتم إيقاف الميزة إلا بعد الإصدار 114 من متصفّح Chrome.

  • 12 آب (أغسطس) 2022: تم تعديل المخطّط الزمني ولن يتم إيقافه إلا بعد الإصدار 109 من متصفّح Chrome.

  • 10 شباط (فبراير) 2022: تم نشر مقالة معدّلة في دليل الوصول إلى الشبكة الخاصة: تقديم الطلبات المسبقة.

  • 25 آب (أغسطس) 2021: تم تعديل الإعلان عن المخطط الزمني وإطلاق فترة تجريبية للإيقاف النهائي.

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

سيطرح متصفِّح Chrome التغييرات التالية:

  • حظر الطلبات للشبكات الخاصة من المواقع الإلكترونية العامة غير الآمنة بدءًا من Chrome 94.
  • نقدّم لك فترة تجريبية للإيقاف النهائي ستنتهي في Chrome
    1. سيتيح ذلك للمطوّرين طلب تمديد الموعد النهائي للمصادر التي تم اختيارها، ولن تتأثّر هذه الفترة خلال الفترة التجريبية لعملية الإيقاف النهائي.
  • نقدّم لك سياسة Chrome التي ستسمح لعمليات نشر Chrome المُدارة بتجاوز عملية الإيقاف النهائي نهائيًا. متاح في الإصدار 92 من Chrome.

إذا كنت بحاجة إلى مزيد من الوقت للتخفيف من تأثير سجلّ الإيقاف النهائي في الفترة التجريبية للإيقاف النهائي.

إذا كان لديك تحكُّم إداري في المستخدمين، يمكنك إعادة تفعيل الميزة باستخدام سياسات Chrome.

للحدّ من تأثير القيود الجديدة، استخدِم إحدى الاستراتيجيات التالية:

المخطط الزمني

  • تشرين الثاني (نوفمبر) 2020: يُرجى الاتصال بنا لتلقّي الملاحظات حول التغييرات القادمة.
  • مارس 2021: بعد مراجعة الملاحظات والتواصل، يتم الإعلان عن التغييرات القادمة. تتم إعادة تسمية المواصفات من CORS-RFC1918 إلى "الوصول إلى الشبكة الخاصة".
  • نيسان (أبريل) 2021: طرح الإصدار 90 من Chrome في إصدار ثابت ويعرض تحذيرات الإيقاف النهائي
  • حزيران (يونيو) 2021: طرح Chrome 92 في إصدار تجريبي، ما يمنع طلبات الشبكات الخاصة من السياقات غير الآمنة. بعد تلقّي ملاحظات من المطوّرين يطلبون منك وقتًا إضافيًا للتعديل، سيتم تأجيل عملية الإيقاف النهائي إلى الإصدار 93 من Chrome ليكون مصحوبةً بفترة تجريبية للإيقاف.
  • تموز (يوليو) 2021: بعد الحصول على ملاحظات إضافية من المطوِّرين، سيتم تأجيل عملية الإيقاف النهائي والفترة التجريبية المصاحبة لها إلى الإصدار 94 من Chrome. بالإضافة إلى ذلك، لن تتأثر المواقع الإلكترونية الخاصة بالإيقاف.
  • آب (أغسطس) 2021: طرح الإصدار 94 من Chrome في الإصدار التجريبي. يمكن لمطوّري الويب بدء الاشتراك في الفترة التجريبية للإيقاف النهائي
  • أيلول (سبتمبر) 2021: طرح الإصدار 94 من Chrome في القناة الثابتة. يجب أن يكون مطورو الويب قد اشتركوا في تجربة الإيقاف ونشر رموز الفترة التجريبية للإنتاج.
  • كانون الأول (ديسمبر) 2022: تم إرسال الاستطلاع التجريبي الأوّلي وتلقّي الملاحظات والآراء. تم تمديد الفترة التجريبية للإيقاف النهائي إلى Chrome 113.
  • آذار (مارس) 2023: تم تمديد الفترة التجريبية للإيقاف النهائي إلى Chrome 116، وستنتهي في Chrome 117. هناك آلية بديلة مستندة إلى الأذونات قيد التطوير، وتستهدف الإصدار الأولي في Chrome 114.
  • أيار (مايو) 2023 (إجراء مبدئي): يتم طرح الآلية المستندة إلى الأذونات في الإصدار 114 من Chrome. ويمكن للمواقع الإلكترونية استخدامها للخروج من الفترة التجريبية لعملية الإيقاف.
  • أيلول (سبتمبر) 2023: طرح Chrome 117 على القناة الثابتة، ما ينهي الفترة التجريبية للإيقاف النهائي. يحظر Chrome جميع طلبات الشبكة الخاصة من السياقات العامة غير الآمنة.

ما المقصود بالوصول إلى الشبكة الخاصة؟

يحدّ أسلوب الوصول إلى الشبكة الخاصة (المعروف سابقًا باسم CORS-RFC1918) من قدرة المواقع الإلكترونية على إرسال الطلبات إلى الخوادم على الشبكات الخاصة. ولا تسمح بمثل هذه الطلبات إلا من سياقات آمنة. تعمل المواصفات أيضًا على توسيع بروتوكول مشاركة الموارد المتعدّدة المصادر (CORS) بحيث تضطر المواقع الإلكترونية الآن إلى طلب منحة صراحةً من الخوادم على الشبكات الخاصة قبل السماح لها بإرسال طلبات عشوائية.

طلبات الشبكة الخاصة هي الطلبات التي يكون عنوان IP لخادم الهدف أكثر خصوصية من ذلك الذي تم جلب بدء الطلب منه. على سبيل المثال، طلب من موقع إلكتروني علني (https://example.com) إلى موقع إلكتروني خاص (http://router.local)، أو طلب من موقع إلكتروني خاص إلى مضيف محلي.

العلاقة بين الشبكات العامة والخاصة والمحلية في الوصول إلى الشبكة الخاصة (CORS-RFC1918).
العلاقة بين الشبكات العامة والخاصة والمحلية في الوصول إلى الشبكة الخاصة (CORS-RFC1918).

يمكنك الاطّلاع على مزيد من المعلومات على الرابط التعليقات المطلوبة: سياسة مشاركة الموارد المتعددة المصادر (CORS) للشبكات الخاصة (RFC1918).

ما هي تجربة الإيقاف النهائي؟

تجارب الإيقاف النهائي (المعروفة سابقًا باسم تجارب المصدر العكسي) هي شكل من أشكال تجارب المصدر المستخدَمة لتسهيل إيقاف ميزات الويب نهائيًا. تسمح الفترات التجريبية لعملية الإيقاف النهائي لمتصفِّح Chrome بإيقاف ميزات معيّنة على الويب نهائيًا ومنع المواقع الإلكترونية من إنشاء تبعيات جديدة عليها، مع منح المواقع الإلكترونية التابعة الحالية وقتًا إضافيًا للمغادرة منها.

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

لمزيد من المعلومات، اطّلِع على بدء استخدام مراحل التجربة والتقييم في Chrome ودليل مطوّري البرامج على الويب حول الفترات التجريبية المصدر للحصول على التعليمات.

التغييرات في Chrome

Chrome 94

بدءًا من إصدار 94 من Chrome، يُحظر على السياقات العامة غير الآمنة (بشكل عام، المواقع الإلكترونية التي لا يتم تسليمها عبر HTTPS أو من عنوان IP خاص) إرسال طلبات إلى الشبكة الخاصة. كان قد تم التخطيط لذلك في السابق في إصدار 92 من Chrome، وبالتالي قد لا تزال رسائل الإيقاف تشير إلى المعلم الرئيسي السابق.

سيصاحب عملية الإيقاف هذه فترة تجريبية للإيقاف النهائي، ما يسمح لمطوّري البرامج على الويب الذين يستفيدون من هذه الميزة بالاستمرار في استخدامها حتى الإصدار 116 من Chrome من خلال التسجيل للحصول على الرموز المميّزة. يمكنك الاطّلاع أدناه على تعليمات حول كيفية تسجيل الفترة التجريبية وتفعيلها على موقعك الإلكتروني.

يمكن الاستفادة من سياسات Chrome لإيقاف عملية الإيقاف النهائي كليًا أو على مصادر معيّنة إلى أجل غير مسمى. ويتيح ذلك لعمليات تثبيت Chrome المُدارة، على سبيل المثال، تلك المتوفرة في إعدادات الشركة، تجنب التعطُّل.

الإصدار 117 من Chrome

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

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

التسجيل في الفترة التجريبية للإيقاف النهائي

  1. انقر على Register (تسجيل) لتجربة الوصول إلى الشبكة الخاصة من سياقات غير آمنة للحصول على رمز تجريبي للمصدر المشارِك.
  2. أضِف السمة 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 للمواقع الإلكترونية التي تحمل أسماء نطاقات عامة. لتفادي هذا الأمر:

  1. سجِّل اسم نطاق عام (مثلاً intranet.example) وانشر سجلّات نظام أسماء النطاقات التي تشير إلى اسم النطاق هذا إلى خادم عام من اختيارك.
  2. الحصول على شهادة TLS لـ intranet.example.
  3. داخل شبكتك الخاصة، اضبط نظام أسماء النطاقات لتحويل intranet.example إلى عنوان IP الخاص للخادم المستهدف.
  4. يمكنك ضبط خادمك الخاص لاستخدام شهادة بروتوكول أمان طبقة النقل (TLS) للنطاق intranet.example. يتيح ذلك للمستخدمين الوصول إلى الخادم الخاص على https://intranet.example.

يمكنك بعد ذلك ترقية الموقع الإلكتروني الذي يبدأ الطلبات إلى بروتوكول HTTPS ومواصلة إرسال الطلبات كما كان في السابق.

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

WebTransport

لا يتطلب هذا الحل التحكم في التحويل باستخدام نظام أسماء النطاقات (DNS) للمستخدمين. ويتطلب ذلك أن يشغل الخادم المستهدف الحد الأدنى من خادم 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.

لا تُميِّز مواصفات "الوصول إلى الشبكة الخاصة" بين نوعَي عمليات الجلب، واللذين سيخضعان في النهاية للقيود نفسها.

صورة غلاف من إعداد Markus Spiske على موقع Un تحقق