آخر الأخبار
- 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 بيانات التوافق ويتواصل مع أكبر المواقع الإلكترونية المتأثرة.
- ونتوقع أن يكون ذلك متوافقًا بشكل واسع مع المواقع الإلكترونية الحالية.
في الإصدار 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،
وعناوين IP المحلية الفريدة fc00::/7 المحدّدة في RFC4193،
عنوان الرابط المحلي 1 IPv4 الذي تم تحديده في {13/RFC1} الخاص بعنوان IPv4 الخاص.fe80::/10RFC4291
تحتوي المساحة العامة لعنوان IP على جميع العناوين الأخرى التي لم يتم ذكرها سابقًا.
يعتبر عنوان IP المحلي أكثر خصوصية من عنوان IP الخاص الذي يُعتبر أكثر خصوصية من عنوان IP عام.
يمكنك الاطّلاع على مزيد من المعلومات على الرابط التعليقات المطلوبة: سياسة مشاركة الموارد المتعددة المصادر (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
كيفية معرفة ما إذا كان موقعك الإلكتروني قد تأثّر بهذا التغيير
بدءًا من Chrome 104، إذا تم اكتشاف طلب شبكة خاصة، سيتم إرسال طلب مبدئي قبله. إذا تعذّر إرسال الطلب المُسبَق، سيستمر إرسال الطلب الأخير، ولكن سيظهر تحذير في لوحة مشاكل "أدوات مطوري البرامج".
يمكن أيضًا الاطّلاع على طلبات الطلب المُسبَق المتأثّرة بالمشكلة وتشخيصها في لوحة الشبكة:
إذا كان طلبك يؤدي إلى تنفيذ إرسال مبدئي عادي لبروتوكول CORS بدون قواعد "الوصول إلى الشبكة الخاصة"، قد تظهر إرسالان مبدئيتان في لوحة الشبكة، وستبدو الأولى دائمًا على أنها غير ناجحة. هذا خطأ معروف ويمكنك تجاهله.
لمراجعة ما يحدث في حال فرض نجاح الطلب المُسبَق، يمكنك تمرير وسيطة سطر الأوامر التالية، بدءًا من Chrome 98:
--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 والنوافذ المنبثقة. نسعى مبدئيًا إلى أن يبدأ الإصدار 108 من Chrome في عرض التحذيرات.
وفي كلتا الحالتين، سنمضي بحذر في عملية طرح على مراحل مماثلة، من أجل منح مطوري الويب الوقت الكافي لتعديل وتقدير مخاطر التوافق.
شكر وتقدير
صورة غلاف من إعداد Mark Olsen على قناة Un تحقق