التحديثات
- 7 تموز (يوليو) 2022: تم تعديل الحالة الحالية وإضافة تعريف لمساحة عنوان IP.
- 27 نيسان (أبريل) 2022: تم تعديل إشعار المخطط الزمني.
- 7 آذار (مارس) 2022: الإعلان عن العودة إلى الإصدار السابق بعد رصد المشاكل في الإصدار 98 من Chrome.
مقدمة
سيوقف Chrome نهائيًا الوصول المباشر إلى نقاط نهاية الشبكة الخاصة من المواقع العامة. ومواقع الويب كجزء من الوصول الخاص إلى الشبكة (PNA) المواصفات.
سيبدأ Chrome في إرسال طلب طلب CORS المبدئي قبل أي طلب شبكة خاص لمورد فرعي، والذي يطلب
للحصول على إذن صريح من الخادم الهدف. سيتم تطبيق الطلب المبدئي هذا
يحمل عنوانًا جديدًا، وهو Access-Control-Request-Private-Network: true
استجابته لها يجب أن يتضمن عنوانًا مقابلاً،
Access-Control-Allow-Private-Network: true
الهدف هو حماية المستخدمين من هجمات تزوير الطلبات من مواقع إلكترونية متعددة (CSRF). تستهدف أجهزة التوجيه والأجهزة الأخرى على الشبكات الخاصة. لقد أثّرت هذه الهجمات على مئات الآلاف من المستخدمين، السماح للمهاجمين بإعادة توجيههم إلى خوادم ضارة
خطة الطرح
سيطرح Chrome هذا التغيير على مرحلتَين لمنح المواقع الإلكترونية وقتًا لإشعار التغيير والتعديل وفقًا لذلك.
في الإصدار 104 من Chrome:
- تجارب Chrome عن طريق إرسال طلبات ما قبل التنفيذ قبل الشبكة الخاصة طلبات الموارد الفرعية.
- عند تعذُّر إجراء الطلب المبدئي، يتم عرض التحذيرات في "أدوات مطوّري البرامج" فقط بدون خلاف ذلك. تؤثر في طلبات الشبكة الخاصة.
- يجمع Chrome بيانات التوافق ويصل إلى الجهات الأكثر تأثّرًا بالمشكلة. مواقع الويب.
- ونتوقع أن يكون ذلك متوافقًا على نطاق واسع مع المواقع الإلكترونية الحالية.
في إصدار Chrome 113 الأقدم:
- لن يبدأ ذلك إلا إذا كانت بيانات التوافق تشير إلى أنّ التغيير آمن بما فيه الكفاية، وقد تواصلنا معه مباشرةً عند الضرورة.
- يفرض Chrome ضرورة نجاح طلبات الطلب المسبق وإلا لن تنجح الطلبات.
- تبدأ الفترة التجريبية للإيقاف النهائي في الوقت نفسه للسماح للمواقع الإلكترونية المتأثرة بهذه المرحلة بطلب الوقت الإضافي. تستمر الفترة التجريبية لمدة 6 أشهر على الأقل.
ما المقصود بالوصول إلى الشبكة الخاصة (PNA)
الوصول الخاص إلى الشبكة (المعروفة سابقًا باسم CORS-RFC1918) تقييد قدرة المواقع الإلكترونية على إرسال الطلبات إلى الخوادم بخصوصية تامة جديدة.
سبق أن نفّذ Chrome جزءًا من المواصفات: اعتبارًا من الإصدار Chrome 96، سيسري السياقات الآمنة لإجراء طلبات الشبكة الخاصة. يمكنك الرجوع إلى مشاركة المدونة السابقة لمزيد من التفاصيل.
توسّع المواصفات أيضًا مشاركة الموارد المتعدّدة المصادر (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 التي تم ربطها باستخدام الإصدار 4 من بروتوكول IP، والتي يكون فيها عنوان IPv4 المرتبط نفسه خاصًا.
تحتوي مساحة عنوان IP العام على جميع العناوين الأخرى التي لم يتم ذكرها سابقًا.
يعتبر عنوان IP المحلي أكثر خصوصية من عنوان IP الخاص الذي يعتبر أكثر خصوصية من عنوان IP العام.
تعرَّف على مزيد من المعلومات على الرابط Feedbackrequired: 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
سيؤدي أي طلب اختباري أوّلي غير ناجح إلى تعذُّر عملية الجلب. هذا يمكن أن يسمح لك لاختبار ما إذا كان موقعك الإلكتروني سيعمل بعد المرحلة الثانية من خطة الطرح. يمكن تشخيص الأخطاء في تمامًا مثل التحذيرات باستخدام لوحات "أدوات مطوري البرامج" المذكورة أعلاه
ما يجب فعله إذا كان موقعك الإلكتروني متأثرًا
عند طرح هذا التغيير في Chrome 104، لا يُتوقع خرق أي موقعك الإلكتروني. ومع ذلك، ننصحك بشدة بتعديل مسارات الطلبات المتأثرة إلى لضمان استمرار عمل موقعك الإلكتروني كما هو متوقع.
هناك حلان متاحان لك:
- التعامل مع طلبات الطلب المبدئي من جهة الخادم
- إيقاف عمليات التحقّق من PNA باستخدام سياسات المؤسسة
التعامل مع الطلبات الأولية من جهة الخادم
تعديل الخادم الهدف لأي عمليات جلب متأثّرة للتعامل مع الطلب المبدئي لـ 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 والنوافذ المنبثقة. إننا نهدف مبدئيًا إلى بدء تشغيل Chrome 108 عرض التحذيرات.
وفي كلتا الحالتين، سنتابع بحذر مع عملية طرح مماثلة على مراحل، وذلك لمنح مطوري الويب الوقت الكافي لتعديل مخاطر التوافق وتقديرها.
شكر وتقدير
صورة غلاف مارك أولسن على إزالة البداية