آخر الأخبار
- 7 تموز (يوليو) 2022: تم تعديل الحالة الحالية وإضافة تعريف لمساحة عنوان IP.
- 27 نيسان (أبريل) 2022: إعلان بشأن تعديل المخطط الزمني
- 7 آذار (مارس) 2022: تم الإعلان عن التراجع عن التحديث بعد اكتشاف مشاكل في Chrome 98.
مقدمة
سيتوقف Chrome نهائيًا عن السماح بالوصول المباشر إلى نقاط نهاية الشبكة الخاصة من المواقع الإلكترونية العامة كجزء من مواصفات الوصول إلى الشبكة الخاصة (PNA).
سيبدأ Chrome بإرسال طلب التحقّق من CORS قبل أي طلب شبكة خاصة لمورد فرعي، ما يطلب
إذنًا صريحًا من الخادم المستهدَف. سيحمل طلب التحقّق من الصحة هذا
عنوانًا جديدًا، وهو Access-Control-Request-Private-Network: true، ويجب أن يحمل
الاستجابة له عنوانًا متوافقًا، وهو Access-Control-Allow-Private-Network: true.
ويهدف ذلك إلى حماية المستخدمين من هجمات التزوير عبر المواقع الإلكترونية (CSRF) التي تستهدف أجهزة التوجيه والأجهزة الأخرى على الشبكات الخاصة. وقد أثّرت هذه الهجمات في مئات الآلاف من المستخدمين، مما سمح للمهاجمين بإعادة توجيههم إلى خوادم ضارة.
خطة الطرح
سيطرح Chrome هذا التغيير على مرحلتين لإتاحة الوقت للمواقع الإلكترونية لكي تلاحظ التغيير وتتكيّف معه وفقًا لذلك.
في الإصدار 104 من Chrome:
- يجري Chrome تجارب من خلال إرسال طلبات الفحص المُسبَق قبل طلبات الموارد الفرعية للشبكة الخاصة.
- لا تعرِض حالات تعذُّر الفحص المُسبَق سوى تحذيرات في DevTools، بدون أن تؤثر في طلبات الشبكة الخاصة.
- يجمع Chrome بيانات التوافق ويتواصل مع أكبر المواقع الإلكترونية المتأثّرة.
- نتوقع أن يكون هذا الإجراء متوافقًا على نطاق واسع مع المواقع الإلكترونية الحالية.
في الإصدار 113 من Chrome على أقرب تقدير:
- لن يبدأ هذا الإجراء إلا إذا كانت بيانات التوافق تشير إلى أنّه التغيير آمن بما يكفي وتواصلنا معك مباشرةً عند الضرورة.
- يفرض Chrome أن تنجح طلبات التحقّق من التوافق، وإلا سيتم رفض الطلبات.
- تبدأ فترة تجريبية للإيقاف النهائي في الوقت نفسه للسماح للمواقع الإلكترونية المتأثرة بهذه المرحلة بطلب التمديد الزمني. ستستمر الفترة التجريبية لمدة 6 أشهر على الأقل.
ما هو الوصول إلى الشبكة الخاصة (PNA)؟
الوصول إلى الشبكة الخاصة (المعروف سابقًا باسم CORS-RFC1918) يحظر على المواقع الإلكترونية إرسال طلبات إلى الخوادم على الشبكات الخاصة.
نفَّذ Chrome جزءًا من المواصفة: اعتبارًا من الإصدار 96 من Chrome، لا يُسمح إلا للسياقات الآمنة بتقديم طلبات للشبكة الخاصة. يمكنك الرجوع إلى مشاركة المدوّنة السابقة لمعرفة التفاصيل.
وتوسّع المواصفة أيضًا بروتوكول مشاركة الموارد المتعدّدة المصادر (CORS) لكي تطلب المواقع الإلكترونية الآن صراحةً من الخوادم منح الإذن على الشبكات الخاصة قبل السماح لها بإرسال طلبات عشوائية.
كيفية تصنيف PNA لعناوين IP وتحديد شبكة خاصة
يتم تصنيف عناوين IP إلى ثلاث مساحات عناوين IP:
- public
- private
- local
تحتوي مساحة عناوين IP المحلية على عناوين IP التي تكون إما عناوين IPv4
للرجوع إلى الجهاز نفسه (127.0.0.0/8) المحدّدة في القسم 3.2.1.3 من RFC1122
أو عناوين IPv6 للرجوع إلى الجهاز نفسه (::1/128) المحدّدة في القسم 2.5.3 من RFC4291.
تحتوي مساحة عناوين IP الخاصة على عناوين IP التي لها معنى فقط
داخل الشبكة الحالية، بما في ذلك 10.0.0.0/8 و172.16.0.0/12 و
192.168.0.0/16 المحدّدة في RFC1918،
والعناوين المحلية الخاصة بالربط 169.254.0.0/16 المحدّدة في RFC3927،
وعناوين البث الفريد لبروتوكول IPv6 المحلي fc00::/7 المحدّدة في RFC4193،
وعناوين البث الفريد لبروتوكول IPv6 المحلية الخاصة بالربط fe80::/10 المحدّدة في القسم 2.5.6 من RFC4291
وعناوين IPv6 المُعاد توجيهها إلى IPv4 حيث يكون عنوان IPv4 المُعاد توجيهه خاصًا.
تحتوي مساحة عناوين IP العامة على جميع العناوين الأخرى غير المذكورة سابقًا.
يُعدّ عنوان IP المحلي أكثر خصوصية من عنوان IP الخاص الذي يُعدّ بدوره أكثر خصوصية من عنوان IP العام.
اطّلِع على مزيد من المعلومات على مطلوب تقديم ملاحظات: المشاكل المتعلقة بمشاركة موارد عناوين URL التابعة للنطاق نفسه (CORS) على الشبكات الخاصة (RFC1918).
الطلبات التمهيدية
الخلفية
طلبات التحقّق المُسبَق هي آلية أدخلها معيار مشاركة الموارد المنشأة من مصادر متعدّدة (CORS) ويُستخدَم هذه الآلية لطلب الإذن من موقع إلكتروني مستهدف قبل إرسال طلب HTTP إليه قد يكون له آثار جانبية. يضمن ذلك فهم الخادم المستهدَف لبروتوكول CORS ويقلل بشكل كبير من خطر هجمات CSRF.
يتم إرسال طلب الإذن كطلب HTTP من النوع OPTIONS مع رؤوس طلبات سياسة مشاركة الموارد المتعددة المصادر (CORS)
المحدّدة التي تصف طلب HTTP القادم. يجب أن تتضمّن الاستجابة عناوين استجابة CORS محدّدة
توافق صراحةً على الطلب القادم.
الميزات الجديدة في ميزة "الوصول إلى الشبكة الخاصة"
تمّ تقديم زوج جديد من عناوين الطلب والاستجابة لطلبات التحقّق من التوافق:
- تم ضبط
Access-Control-Request-Private-Network: trueعلى جميع طلبات التحقّق من الصحة لـ PNA - يجب ضبط
Access-Control-Allow-Private-Network: trueعلى جميع استجابات الفحص المُسبَق لـ PNA
يتم إرسال طلبات التحقّق من الصحة لبروتوكول PNA لجميع طلبات الشبكات الخاصة،
بغض النظر عن طريقة الطلب و
وضعه. ويتم إرسالها
قبل الطلبات في وضع cors بالإضافة إلى وضع no-cors وجميع الأوضاع الأخرى. ويعود سبب ذلك
إلى أنّه يمكن استخدام جميع طلبات الشبكة الخاصة في هجمات CSRF،
بغض النظر عن وضع الطلب وما إذا كانت محتويات الردّ متاحة
للمُشغِّل أم لا.
يتم أيضًا إرسال طلبات التحقّق من الصحة لبروتوكول PNA لطلبات المصدر نفسه، إذا كان عنوان IP المستهدف أكثر خصوصية من عنوان IP المُشغِّل. يختلف ذلك عن طلبات CORS العادية، حيث تكون طلبات الفحص المُسبَق مخصّصة فقط لطلبات مصادر مختلفة. طلبات التحقّق المُسبَق لطلبات المصدر نفسه تحمي من هجمات إعادة ربط نظام أسماء النطاقات.
أمثلة
يعتمد السلوك الملحوظ على وضع الطلب.
وضع عدم سياسة مشاركة الموارد المتعددة المصادر (CORS)
لنفترض أنّ https://foo.example/index.html تضمّن
<img src="https://bar.example/cat.gif" alt="dancing cat"/>، و
bar.example يُحدّد على أنّه 192.168.1.1، وهو عنوان IP خاص وفقًا
لمعيار RFC 1918.
يُرسِل Chrome أولاً طلب التحقّق من الصحة:
HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true
لكي ينجح هذا الطلب، يجب أن يردّ الخادم بما يلي:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true
بعد ذلك، سيُرسِل Chrome الطلب الفعلي:
HTTP/1.1 GET /cat.gif
...
يمكن للخادم الردّ عليها بشكلٍ طبيعي.
وضع سياسة مشاركة الموارد المتعددة المصادر (CORS)
لنفترض أنّ https://foo.example/index.html ينفِّذ التعليمة البرمجية التالية:
await fetch('https://bar.example/delete-everything', {
method: 'PUT',
credentials: 'include',
})
مرة أخرى، لنفترض أنّ bar.example يُحيل إلى 192.168.1.1.
يُرسِل Chrome أولاً طلب التحقّق من الصحة:
HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true
لكي ينجح هذا الطلب، يجب أن يردّ الخادم بما يلي:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true
بعد ذلك، سيُرسِل Chrome الطلب الفعلي:
HTTP/1.1 PUT /delete-everything
Origin: https://foo.example
يمكن للخادم الردّ على الطلبات وفقًا لقواعد CORS المعتادة:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example
كيفية معرفة ما إذا كان موقعك الإلكتروني متأثرًا
بدءًا من الإصدار 104 من Chrome، إذا تم رصد طلب شبكة خاصة، سيتم إرسال طلب فحص مبدئي قبله. إذا تعذّر طلب التحقّق من التوافق هذا، سيظلّ الطلب النهائي مُرسَلاً، ولكن سيظهر تحذير في لوحة المشاكل في "أدوات المطوّر".
يمكن أيضًا عرض طلبات التحقّق من التوافق المتأثّرة وتحديد المشاكل فيها في لوحة الشبكة:
إذا كان طلبك سيؤدي إلى إجراء فحص عادي للطلب المبدئي لبروتوكول مشاركة الموارد المشتركة المنشأ (CORS) بدون قواعد الوصول إلى الشبكة الخاصة، قد تظهر عمليات فحص طلب مبدئيان في لوحة الشبكة، ويبدو أنّه تم رفض الأول دائمًا. هذا هو خطأ معروف، ويمكنك تجاهله بأمان.
لمراجعة ما يحدث في حال فرض نجاح عملية التحقّق من التشغيل، يمكنك تمرير الوسيطة التالية لسطر الأوامر، بدءًا من الإصدار 98 من Chrome:
--enable-features=PrivateNetworkAccessRespectPreflightResults
سيؤدي أي طلب تحقّق من الصحة تعذّر تنفيذه إلى تعذّر استرجاع البيانات. يمكن أن يتيح لك ذلك اختبار ما إذا كان موقعك الإلكتروني سيعمل بعد المرحلة الثانية من خطة الطرح. يمكن تشخيص الأخطاء بالطريقة نفسها التي يتم بها تشخيص التحذيرات باستخدام لوحات أدوات المطوّرين المذكورة أعلاه.
الإجراءات التي يجب اتّخاذها إذا كان موقعك الإلكتروني متأثرًا
عند طرح هذا التغيير في الإصدار 104 من Chrome، من المتوقّع ألا يؤدي إلى إيقاف أي موقع إلكتروني. مع ذلك، ننصحك بشدة بتعديل مسارات الطلبات المتأثّرة لضمان مواصلة تشغيل موقعك الإلكتروني على النحو المتوقّع.
يتوفّر لك خياران:
- معالجة طلبات التحقّق من الصحة من جهة الخادم
- إيقاف عمليات التحقّق من عناوين IP الخاصة بالعملاء باستخدام سياسات المؤسسة
معالجة طلبات الفحص المُسبَق من جهة الخادم
عدِّل الخادم المستهدَف لأي عمليات جلب متأثرة لمعالجة طلبات التحقّق من الإعداد المسبق لـ PNA. أولاً، عليك توفير إمكانية استخدام طلبات التحقّق من CORS العادية في ملف تعريف الارتباط على مسار التحويل المعني. بعد ذلك، أضِف إمكانية استخدام عنوانَي استجابة جديدَين.
عندما يتلقّى خادمك طلبًا تمهيديًا (طلب OPTIONS يحتوي على عناوين CORS
)، يجب أن يتحقّق الخادم من توفّر عنوان
Access-Control-Request-Private-Network: true. إذا كان هذا الرأس
موجودًا في الطلب، يجب أن يفحص الخادم رأس Origin و
مسار الطلب بالإضافة إلى أي معلومات أخرى ذات صلة (مثل
Access-Control-Request-Headers) للتأكّد من أنّه من الآمن السماح بالطلب.
وعادةً ما يجب السماح بالوصول إلى مصدر واحد تحت سيطرتك.
بعد أن يقرر خادمك السماح بالطلب، من المفترض أن يستجيب بالرمز204 No Content (أو 200 OK) مع رؤوس CORS اللازمة وعنوان PNA الجديد. وتشمل هذه العناوين Access-Control-Allow-Origin و
Access-Control-Allow-Private-Network: true، بالإضافة إلى عناوين أخرى حسب الحاجة.
راجِع الأمثلة للاطّلاع على سيناريوهات محدّدة.
إيقاف عمليات التحقّق من الوصول إلى الشبكة الخاصة باستخدام سياسات المؤسسة
إذا كان لديك تحكّم إداري في المستخدمين، يمكنك إيقاف عمليات التحقّق من الوصول إلى الشبكة الخاصة باستخدام أيّ من السياستَين التاليتَين:
لمزيد من المعلومات، يُرجى الاطّلاع على المقالة التعرّف على إدارة سياسات Chrome.
أرسل لنا تعليقاتك
إذا كنت تستضيف موقعًا إلكترونيًا ضمن شبكة خاصة تتوقّع طلبات من الشبكات العامة، يهتم فريق Chrome بملاحظاتك وحالات الاستخدام.
يُرجى إعلامنا بذلك من خلال الإبلاغ عن مشكلة في Chromium على الرابط crbug.com وضبط
المكوّن على Blink>SecurityFeature>CORS>PrivateNetworkAccess.
الخطوات التالية
في الخطوة التالية، سيوسّع Chrome عمليات التحقّق من الوصول إلى الشبكة الخاصة ليشمل عمال الويب: عمال مخصّصون وعمال مشترَكون وعمال خدمات. نهدف بشكلٍ مؤقت إلى بدء عرض التحذيرات في الإصدار 107 من Chrome.
بعد ذلك، سيوسّع Chrome عمليات التحقّق من الوصول إلى الشبكة الخاصة لتشمل عمليات التنقّل، بما في ذلك إطارات iframe والنوافذ المنبثقة. نهدف إلى بدء عرض التحذيرات في الإصدار 108 من Chrome.
وفي كلتا الحالتَين، سننفّذ الطرح على مراحل بشكل حذر، لمنح مطوّري الويب الوقت للتكيّف مع التغييرات وتقدير مخاطر التوافق.
الشكر والتقدير
صورة الغلاف مقدمة من مارك أولسن على Unsplash.