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

Maud Nalpas

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

ملخّص

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

أساسيات سياسة المُحيل والمُحيل

يمكن أن تتضمن طلبات HTTP عنوان Referer اختياريًا، الذي يشير إلى المصدر أو عنوان 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 المتاحة. من عنوان المُحيل وdocument.referrer:

توفر MDN قائمة كاملة بالسياسات والسلوكيات الأمثلة.

في ما يلي بعض النقاط التي يجب أن تكون على دراية بها عند ضبط سياسة المُحيل:

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

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

اعتبارًا من تشرين الأول (أكتوبر) 2021

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

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

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

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

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

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

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 للاطّلاع على سياسة المُحيل المستخدمة في طلب محدد. في وقت كتابة هذا التقرير، سفاري لا يعرض عنوان 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 المسموح بها التي أعدّها التجّار. إذا كان لا يتطابق مع أي إدخال في القائمة، يرفض payment-provider.example الطلب. إذا كان بشكل مطابق، يمكن للمستخدم متابعة المعاملة.

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

بصفتك مقدّم خدمات دفع، يمكنك استخدام 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)
• سياسة المُحيل في رقم MDN
• عنوان المُحيل: المخاوف المتعلقة بالخصوصية والأمان على رقم MDN
• تغيير في Chrome: هدف Blink to التنفيذ
• تغيير في Chrome: هدف Blink to سفينة
• تغيير Chrome: إدخال الحالة
• تغيير في Chrome: الإصدار 85 التجريبي blogpost
• المُحيل لاقتطاع سلسلة GitHub: ما هي المتصفحات المختلفة إجراء
• مواصفات سياسة المُحيل

مع أطيب التحيات، "ديفيد فان كليف" و"مايك ويست" و"سام دوتون" و"روان ميروود" و"جيكسك" و"كايس باسكيس"