أفضل الممارسات المتعلقة بسياسة المُحيلين والمحيلين

Maud Nalpas

توضّح هذه الصفحة بعض أفضل الممارسات لضبط سياسة المُحيل واستخدام المُحيل في الطلبات الواردة.

ملخّص

• يؤدي تسرُّب المعلومات غير المتوقّع من مصادر خارجية إلى الإضرار بخصوصية مستخدمي الويب. ويمكن أن تساعد سياسة المُحيل الوقائية في ذلك.
• ننصحك بضبط سياسة المُحيل على strict-origin-when-cross-origin. تحافظ هذه السياسة على معظم فوائد المُحيل، مع الحدّ من خطر تسرُّب البيانات من مصادر خارجية.
• لا تستخدِم المُحيلين للحماية من هجمات تزوير الطلبات من مواقع إلكترونية مختلفة (CSRF). استخدِم بدلاً من ذلك رموز CSRF وعناوين أخرى كطبقة أمان إضافية.

مفاهيم أساسية حول العنوانَين Referer وReferrer-Policy

يمكن أن تتضمّن طلبات HTTP عنوانًا اختياريًا هو Referer header، يشير إلى المصدر أو عنوان URL لصفحة الويب التي تم إرسال الطلب منها. يحدّد العنوان Referrer-Policy البيانات التي يتم توفيرها في العنوان Referer.

في المثال التالي، يتضمّن العنوان Referer عنوان URL الكامل للصفحة على site-one التي تم إرسال الطلب منها.

قد يظهر العنوان Referer في أنواع مختلفة من الطلبات:

• طلبات التنقّل، عندما ينقر المستخدم على رابط
• طلبات الموارد الفرعية، عندما يطلب المتصفح صورًا وإطارات iframe ونصوصًا برمجية وموارد أخرى تحتاج إليها الصفحة

بالنسبة إلى عمليات التنقّل وإطارات iframe، يمكنك أيضًا الوصول إلى هذه البيانات باستخدام JavaScript من خلال document.referrer.

يمكنك استخلاص الكثير من المعلومات من قيم Referer. على سبيل المثال، قد تستخدمها خدمة إحصاءات لتحديد أنّ% 50 من الزوّار على site-two.example جاءوا من social-network.example. ولكن عندما يتم إرسال عنوان URL الكامل، بما في ذلك المسار و سلسلة طلب البحث، في Referer من مصادر خارجية، يمكن أن يعرّض ذلك خصوصية المستخدم للخطر ويؤدي إلى مخاطر أمنية:

تحتوي عناوين URL من #1 إلى #5 على معلومات خاصة، وأحيانًا معلومات حساسة أو معلومات تكشف الهوية. ويمكن أن يؤدي تسرُّب هذه المعلومات بدون علم المستخدمين من مصادر خارجية إلى تعريض خصوصية مستخدمي الويب للخطر.

عنوان URL #6 هو عنوان URL للإمكانية. إذا تلقّى أي مستخدم آخر غير المستخدم المقصود هذا العنوان، يمكن أن يتحكّم جهة مسيئة في حساب هذا المستخدم.

لتقييد بيانات المُحيل التي يتم توفيرها للطلبات من موقعك الإلكتروني، يمكنك ضبط سياسة المُحيل.

ما هي السياسات المتاحة وما هي أوجه الاختلاف بينها؟

يمكنك اختيار إحدى السياسات الثماني. استنادًا إلى السياسة، يمكن أن تكون البيانات المتاحة من العنوان Referer (وdocument.referrer) على النحو التالي:

• بدون بيانات (لا يظهر العنوان Referer)
• المصدر فقط
• عنوان URL الكامل: المصدر والمسار وسلسلة طلب البحث

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

يوضّح الجدول التالي كيف تقيّد سياسات المُحيل بيانات عنوان URL المتاحة من العنوان Referer وdocument.referrer:

تقدّم شبكة مطوّري Mozilla (MDN) قائمة كاملة بالسياسات وأمثلة على السلوك.

في ما يلي بعض النقاط التي يجب الانتباه إليها عند ضبط سياسة المُحيل:

• تتعامل جميع السياسات التي تأخذ المخطط (HTTPS مقابل HTTP) في الاعتبار (strict-origin وno-referrer-when-downgrade و strict-origin-when-cross-origin) مع الطلبات من مصدر HTTP إلى مصدر HTTP آخر بالطريقة نفسها التي تتعامل بها مع الطلبات من مصدر HTTPS إلى مصدر HTTPS آخر، حتى إذا كان HTTP أقل أمانًا. ويرجع ذلك إلى أنّه بالنسبة إلى هذه السياسات، ما يهم هو ما إذا كان هناك تخفيض في مستوى الأمان، أي ما إذا كان الطلب يمكن أن يعرّض بيانات من مصدر مشفّر إلى مصدر غير مشفّر، كما في طلبات HTTPS ← HTTP. إنّ طلب HTTP ← HTTP غير مشفّر تمامًا، لذا لا يحدث أي تخفيض في مستوى الأمان.
• إذا كان الطلب من المصدر نفسه، يعني ذلك أنّ المخطط (HTTPS أو HTTP) هو نفسه، لذا لا يحدث أي تخفيض في مستوى الأمان.

سياسات المُحيل التلقائية في المتصفحات

اعتبارًا من أكتوبر 2021

إذا لم يتم ضبط سياسة المُحيل، يستخدم المتصفح سياسته التلقائية.

أفضل الممارسات لضبط سياسة المُحيل

هناك طرق مختلفة لضبط سياسات المُحيل لموقعك الإلكتروني:

• كعنوان HTTP
• ضمن HTML
• من JavaScript على أساس كل طلب

يمكنك ضبط سياسات مختلفة لصفحات أو طلبات أو عناصر مختلفة.

كل من عنوان HTTP وعنصر العلامة الوصفية على مستوى الصفحة. يكون ترتيب الأولوية لتحديد السياسة الفعّالة لعنصر معيّن على النحو التالي:

1. السياسة على مستوى العنصر
2. السياسة على مستوى الصفحة
3. الإعدادات التلقائية للمتصفح

مثال:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

يتم طلب الصورة باستخدام سياسة no-referrer-when-downgrade، وتتّبع جميع طلبات الموارد الفرعية الأخرى من هذه الصفحة سياسة strict-origin-when-cross-origin.

كيف يمكن الاطّلاع على سياسة المُحيل؟

يُعدّ موقع securityheaders.com مفيدًا لتحديد السياسة التي يستخدمها موقع إلكتروني أو صفحة معيّنة.

يمكنك أيضًا استخدام أدوات مطوّري البرامج في Chrome أو Edge أو Firefox للاطّلاع على سياسة المُحيل المستخدَمة لطلب معيّن. في وقت كتابة هذه المقالة، لا يعرض Safari العنوان Referrer-Policy، ولكنه يعرض Referer الذي تم إرساله.

ما هي السياسة التي يجب ضبطها لموقعك الإلكتروني؟

ننصحك بشدة بضبط سياسة تعزّز الخصوصية بشكل صريح، مثل strict-origin-when-cross-origin (أو سياسة أكثر صرامة).

لماذا "بشكل صريح"؟

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

• تختلف السياسات التلقائية في المتصفحات المختلفة، لذا إذا اعتمدت على الإعدادات التلقائية للمتصفح، لن يتصرف موقعك الإلكتروني بشكل متوقّع على مستوى المتصفحات.
• تعتمد المتصفحات إعدادات تلقائية أكثر صرامة، مثل strict-origin-when-cross-origin وآليات مثل حذف المُحيل للطلبات من مصادر خارجية. إنّ الموافقة بشكل صريح على سياسة تعزّز الخصوصية قبل تغيير الإعدادات التلقائية للمتصفح تمنحك التحكّم وتساعدك في إجراء الاختبارات بالطريقة التي تناسبك.

لماذا strict-origin-when-cross-origin (أو سياسة أكثر صرامة)؟

أنت بحاجة إلى سياسة آمنة وتعزّز الخصوصية ومفيدة. يعتمد معنى "مفيدة" على ما تريده من المُحيل:

• آمنة: إذا كان موقعك الإلكتروني يستخدم HTTPS (وإذا لم يكن كذلك، اجعله أولوية)، لا تريد أن يتم تسرُّب عناوين URL لموقعك الإلكتروني في طلبات غير HTTPS. بما أنّه يمكن لأي مستخدم على الشبكة الاطّلاع على هذه العناوين، فإنّ عمليات التسرُّب ستعرّض مستخدميك لهجمات الوسيط. تحلّ السياسات no-referrer-when-downgrade وstrict-origin-when-cross-origin وno-referrer و وstrict-origin هذه المشكلة.
• تعزّز الخصوصية: بالنسبة إلى طلب من مصدر خارجي، no-referrer-when-downgrade تشارك عنوان URL الكامل، ما قد يؤدي إلى مشاكل في الخصوصية. لا تشارك سياستا strict-origin-when-cross-origin وstrict-origin سوى المصدر، ولا تشارك سياسة no-referrer أي بيانات على الإطلاق. يمنحك ذلك الخيارات strict-origin-when-cross-origin وstrict-origin وno-referrer كخيارات تعزّز الخصوصية.
• مفيدة: لا تشارك سياستا no-referrer وstrict-origin عنوان URL الكامل أبدًا، حتى بالنسبة إلى الطلبات من المصدر نفسه. إذا كنت بحاجة إلى عنوان URL الكامل، فإنّ strict-origin-when-cross-origin هو خيار أفضل.

يعني كل ذلك أنّ strict-origin-when-cross-origin هو خيار معقول بشكل عام.

مثال: ضبط سياسة strict-origin-when-cross-origin

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

أو من جهة الخادم، مثلاً في Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

ماذا لو لم تستوعب سياسة strict-origin-when-cross-origin (أو سياسة أكثر صرامة) جميع حالات الاستخدام؟

في هذه الحالة، اتّبِع نهجًا تدريجيًا: اضبط سياسة وقائية مثل strict-origin-when-cross-origin لموقعك الإلكتروني، وإذا لزم الأمر، سياسة أكثر تساهلاً لطلبات أو عناصر HTML معيّنة.

مثال: السياسة على مستوى العنصر

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

قد يحدّ Safari/WebKit من document.referrer أو العنوان Referer للطلبات من مواقع إلكترونية مختلفة. الاطّلاع على التفاصيل.

مثال: السياسة على مستوى الطلب

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

ما هي الجوانب الأخرى التي يجب أخذها في الاعتبار؟

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

أفضل الممارسات للطلبات الواردة

في ما يلي بعض الإرشادات حول ما يجب فعله إذا كان موقعك الإلكتروني يستخدم عنوان URL للمُحيل للطلبات الواردة.

حماية بيانات المستخدمين

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

يمكن أن تتغيّر المُحيلون الواردون {referer-can-change}

يفرض استخدام المُحيل من الطلبات الواردة من مصادر خارجية بعض القيود:

• إذا لم يكن لديك أي تحكّم في عملية التنفيذ الخاصة بمرسِل الطلب، لا يمكنك وضع افتراضات بشأن العنوان Referer (وdocument.referrer) الذي تتلقّاه. قد يقرّر مرسِل الطلب التبديل إلى سياسة no-referrer في أي وقت ، أو بشكل عام إلى سياسة أكثر صرامة من السياسة التي كان يستخدمها من قبل. يعني ذلك أنّك تتلقّى بيانات أقل من Referer مقارنةً بما كنت تتلقّاه من قبل.
• تستخدم المتصفحات بشكل متزايد سياسة المُحيل strict-origin-when-cross-origin تلقائيًا. يعني ذلك أنّه قد لا تتلقّى الآن سوى المصدر، بدلاً من عنوان URL كامل للمُحيل، في الطلبات الواردة من مصادر خارجية، إذا لم يضبط الموقع الإلكتروني المرسِل أي سياسة.
• قد تغيّر المتصفحات طريقة إدارة Referer. على سبيل المثال، قد يقرّر بعض مطوّري المتصفحات حذف المُحيلين دائمًا للمصادر في طلبات الموارد الفرعية من مصادر خارجية، لحماية خصوصية المستخدم.
• قد يحتوي العنوان Referer (وdocument.referrer) على بيانات أكثر مما تحتاج إليه. على سبيل المثال، قد يحتوي على عنوان URL كامل عندما تريد فقط معرفة ما إذا كان الطلب من مصدر خارجي.

بدائل Referer

قد تحتاج إلى أخذ بدائل في الاعتبار في الحالات التالية:

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

لتحديد البدائل، عليك أولاً تحليل جزء المُحيل الذي تستخدمه.

إذا كنت بحاجة إلى المصدر فقط

• إذا كنت تستخدم المُحيل في نص برمجي يمكنه الوصول إلى الصفحة على المستوى الأعلى، فإنّ window.location.origin هو بديل.
• إذا كانت العناوين مثل Origin و Sec-Fetch-Site متاحة، فإنّها تمنحك Origin أو توضّح ما إذا كان الطلب من مصدر خارجي، وهو ما قد تحتاج إليه بالضبط.

إذا كنت بحاجة إلى عناصر أخرى من عنوان URL (المسار، ومَعلمات طلب البحث…)

• قد تعالج مَعلمات الطلب حالة الاستخدام، ما يوفّر عليك عناء تحليل المُحيل.
• إذا كنت تستخدم المُحيل في نص برمجي يمكنه الوصول إلى الصفحة على المستوى الأعلى، قد يكون window.location.pathname بديلاً. استخرِج قسم المسار فقط من عنوان URL ومرِّره كوسيطة، حتى لا يتم تمرير أي معلومات حساسة محتمَلة في مَعلمات عنوان URL.

إذا لم تتمكّن من استخدام هذه البدائل:

• تحقَّق مما إذا كان بإمكانك تغيير أنظمتك لتتوقع من مرسِل الطلب (على سبيل المثال، site-one.example) ضبط المعلومات التي تحتاج إليها بشكل صريح في نوع من الإعدادات.
  • الميزة: أكثر وضوحًا، ويحافظ على خصوصية مستخدمي site-one.example بشكل أفضل، وأكثر ملاءمة للمستقبل
  • العيب: قد يتطلب ذلك المزيد من العمل من جانبك أو من جانب مستخدمي نظامك.
• تحقَّق مما إذا كان الموقع الإلكتروني الذي يرسِل الطلبات قد يوافق على ضبط سياسة المُحيل no-referrer-when-downgrade على مستوى العنصر أو على مستوى الطلب.
  • العيب: قد يحافظ على خصوصية مستخدمي site-one.example بشكل أقل، وقد لا يكون متوافقًا مع جميع المتصفحات.

الحماية من هجمات تزوير الطلبات من مواقع إلكترونية مختلفة (CSRF)

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

استخدِم رموز CSRF كحماية أساسية. لمزيد من الحماية، استخدِم SameSite، و بدلاً من Referer، استخدِم عناوين مثل Origin (متاحة لطلبات POST وCORS) و Sec-Fetch-Site إذا كانت متاحة.

التسجيل وتحديد المشاكل وحلّها

تأكّد من حماية البيانات الشخصية أو البيانات الحسّاسة للمستخدمين التي قد تكون في Referer.

إذا كنت تستخدم المصدر فقط، تحقَّق مما إذا كان بإمكانك استخدام الـ Origin كـ بديل. قد يمنحك ذلك المعلومات التي تحتاج إليها لأغراض تحديد المشاكل وحلّها بطريقة أبسط وبدون الحاجة إلى تحليل المُحيل.

الدفعات

قد يعتمد مورّدو خدمات الدفع على العنوان Referer للطلبات الواردة لإجراء عمليات التحقّق من الأمان.

على سبيل المثال:

• ينقر المستخدم على الزر شراء في online-shop.example/cart/checkout.
• تتم إعادة توجيه online-shop.example إلى payment-provider.example لإدارة المعاملة.
• يتحقّق payment-provider.example من Referer لهذا الطلب مقارنةً بقائمة قيم Referer المسموح بها التي أعدّها التجّار. إذا لم يتطابق `Referer` مع أي إدخال في القائمة، يرفض payment-provider.example الطلب. إذا تطابق `Referer` مع أحد الإدخالات، يمكن للمستخدم المتابعة إلى المعاملة.

أفضل الممارسات لعمليات التحقّق من أمان عملية الدفع

بصفتك مورّد خدمات دفع، يمكنك استخدام Referer كعملية تحقّق أساسية ضد بعض الهجمات. ومع ذلك، فإنّ العنوان Referer وحده ليس أساسًا موثوقًا لعملية التحقّق. يمكن للموقع الإلكتروني الذي يرسِل الطلب، سواء كان تاجرًا شرعيًا أم لا، ضبط سياسة no-referrer تجعل معلومات Referer غير متاحة لمورّد خدمات الدفع.

قد يساعد الاطّلاع على Referer مورّدي خدمات الدفع في رصد الجهات المهاجمة الساذجة التي لم تضبط سياسة no-referrer. إذا كنت تستخدم Referer كعملية تحقّق أولى:

• لا تتوقّع أن يكون Referer متاحًا دائمًا. إذا كان متاحًا، تحقَّق منه مقارنةً بالحد الأدنى من البيانات التي يمكن أن يتضمّنها، وهو المصدر.
  • عند ضبط قائمة قيم Referer المسموح بها، تأكّد من تضمين المصدر فقط وعدم تضمين أي مسار.
  • على سبيل المثال، يجب أن تكون قيم Referer المسموح بها لـ online-shop.example هي online-shop.example، وليس online-shop.example/cart/checkout. من خلال توقّع عدم توفّر Referer على الإطلاق أو توفّر قيمة Referer هي مصدر الموقع الإلكتروني الذي يرسِل الطلب فقط، يمكنك منع الأخطاء التي قد تنتج عن وضع افتراضات بشأن Referrer-Policy الخاصّة بالتاجر.
• إذا لم يكن Referer متاحًا، أو إذا كان متاحًا ونجحت عملية التحقّق الأساسية من مصدر Referer، يمكنك الانتقال إلى طريقة تحقّق أخرى أكثر موثوقية.

للتحقّق من الدفعات بشكل أكثر موثوقية، اطلب من مقدِّم الطلب تجزئة مَعلمات الطلب مع مفتاح فريد. يمكن لمورّدي خدمات الدفع بعد ذلك حساب التجزئة نفسها من جانبك وقبول الطلب فقط إذا كان مطابقًا للحساب الذي أجريته.

ماذا يحدث لـ Referer عندما تتم إعادة توجيه موقع إلكتروني تجاري يستخدم HTTP ولا يتضمّن سياسة مُحيل إلى مورّد خدمات دفع يستخدم HTTPS؟

لا يظهر أي Referer في الطلب المقدَّم إلى مورّد خدمات الدفع الذي يستخدم HTTPS، لأنّ معظم المتصفحات تستخدم strict-origin-when-cross-origin أو no-referrer-when-downgrade تلقائيًا عندما لا يضبط الموقع الإلكتروني أي سياسة. لن يؤدي تغيير Chrome إلى سياسة تلقائية جديدة إلى تغيير هذا السلوك.

الخاتمة

تُعدّ سياسة المُحيل الوقائية طريقة رائعة لمنح مستخدميك المزيد من الخصوصية.

لمزيد من المعلومات عن التقنيات المختلفة لحماية مستخدميك، يُرجى الاطّلاع على مجموعة المحتوى الآمن والمحمي

الموارد

• فهم مصطلحَي "الموقع الإلكتروني نفسه" و"المصدر نفسه"
• عنوان أمان جديد: سياسة المُحيل (2017)
• ‫Referrer-Policy على شبكة مطوّري Mozilla (MDN)
• عنوان Referer: مخاوف بشأن الخصوصية والأمان على شبكة مطوّري Mozilla (MDN)
• تغيير Chrome: نية Blink في التنفيذ
• تغيير Chrome: نية Blink في إطلاق الميزة
• تغيير Chrome: إدخال الحالة
• تغيير Chrome: مشاركة مدونة الإصدار التجريبي 85
• سلسلة محادثات على GitHub حول حذف المُحيل: ما تفعله المتصفحات المختلفة
• مواصفات Referrer-Policy

نشكر جميع المراجعين على مساهماتهم وملاحظاتهم، وخاصةً Kaustubha Govind وDavid Van Cleve وMike West وSam Dutton وRowan Merewood وJxck وKayce Basques.