آخر الأخبار
- 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 عن طريق إرسال طلبات الاختبار المسبق قبل طلبات الموارد الفرعية للشبكة الخاصة.
- لا تعرض حالات تعذُّر الفحص المُسبَق سوى تحذيرات في "أدوات مطوّري البرامج"، بدون أن تؤثر على طلبات الشبكة الخاصة.
- يجمع 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 المستهدفًا أكثر خصوصية من بادئ التشغيل. يختلف ذلك عن طلبات 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.