بهترین شیوه های ارجاع و ارجاع-سیاست

Maud Nalpas

این صفحه برخی از بهترین روش‌ها را برای تنظیم خط‌مشی ارجاع‌دهنده و استفاده از ارجاع‌دهنده در درخواست‌های دریافتی نشان می‌دهد.

خلاصه

• نشت اطلاعات متقابل غیرمنتظره به حریم خصوصی کاربران وب آسیب می رساند. یک خط مشی ارجاع حفاظتی می تواند کمک کند.
• در نظر بگیرید که یک خط مشی ارجاع دهنده با strict-origin-when-cross-origin تنظیم کنید. این بیشتر سودمندی ارجاع دهنده را حفظ می کند، در حالی که خطر نشت منابع متقاطع داده ها را کاهش می دهد.
• از ارجاع‌دهنده‌ها برای محافظت از جعل درخواست متقابل (CSRF) استفاده نکنید. به جای آن از توکن‌های CSRF و سایر هدرها به عنوان یک لایه امنیتی اضافی استفاده کنید.

ارجاع و ارجاع - سیاست 101

درخواست‌های HTTP می‌تواند شامل یک سرصفحه Referer اختیاری باشد که نشان‌دهنده مبدا یا URL صفحه وب است که درخواست از آن انجام شده است. هدر Referrer-Policy مشخص می‌کند که چه داده‌هایی در سرصفحه Referer در دسترس هستند.

در مثال زیر، هدر Referer شامل URL کامل صفحه در site-one است که درخواست از آن انجام شده است.

هدر Referer ممکن است در انواع مختلفی از درخواست ها وجود داشته باشد:

• درخواست های ناوبری، زمانی که کاربر روی یک پیوند کلیک می کند.
• درخواست‌های منبع فرعی، زمانی که یک مرورگر تصاویر، iframe، اسکریپت‌ها و سایر منابع مورد نیاز یک صفحه را درخواست می‌کند.

برای پیمایش ها و iframe ها، می توانید با استفاده از 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 به یک منبع HTTPS دیگر، حتی اگر HTTP امنیت کمتری داشته باشد. دلیل آن این است که برای این سیاست ها، آنچه اهمیت دارد این است که آیا یک تنزل رتبه امنیتی صورت می گیرد یا خیر. یعنی اگر درخواست بتواند داده ها را از یک مبدأ رمزگذاری شده در معرض یک منبع رمزگذاری نشده قرار دهد، مانند درخواست های HTTPS → HTTP. یک درخواست HTTP → HTTP کاملاً رمزگذاری نشده است، بنابراین هیچ تنزلی وجود ندارد.
• اگر درخواستی با منشاء یکسان باشد، به این معنی است که طرح (HTTPS یا HTTP) یکسان است، بنابراین هیچ کاهش امنیتی وجود ندارد.

سیاست های ارجاع پیش فرض در مرورگرها

از اکتبر 2021

اگر خط مشی ارجاعی تنظیم نشده باشد، مرورگر از خط مشی پیش فرض خود استفاده می کند.

بهترین شیوه ها برای تنظیم خط مشی ارجاع دهنده

راه های مختلفی برای تنظیم سیاست های ارجاع دهنده برای سایت شما وجود دارد:

• به عنوان یک هدر HTTP
• در HTML شما
• از جاوا اسکریپت بر اساس هر درخواست

می توانید خط مشی های مختلفی را برای صفحات، درخواست ها یا عناصر مختلف تنظیم کنید.

هدر 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 برای تعیین اینکه یک سایت یا صفحه خاص از کدام خط‌مشی استفاده می‌کند مفید است.

همچنین می‌توانید از ابزارهای توسعه‌دهنده در کروم، اج یا فایرفاکس برای مشاهده خط‌مشی ارجاع‌دهنده استفاده شده برای یک درخواست خاص استفاده کنید. در زمان نگارش این مقاله، سافاری هدر 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 دریافت می کنید.
• مرورگرها به طور فزاینده ای از Referrer-Policy 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 شما موفقیت آمیز باشد، می‌توانید به روش تأیید صحت مطمئن‌تر دیگری بروید.

برای تأیید مطمئن‌تر پرداخت‌ها، به درخواست‌کننده اجازه دهید پارامترهای درخواست را همراه با یک کلید منحصر به فرد هش کند . سپس ارائه دهندگان پرداخت می توانند همان هش را در سمت شما محاسبه کنند و فقط در صورتی درخواست را بپذیرند که با محاسبه شما مطابقت داشته باشد.

وقتی یک سایت تاجر HTTP بدون خط‌مشی ارجاع‌دهنده به یک ارائه‌دهنده پرداخت HTTPS هدایت می‌شود، چه اتفاقی برای Referer می‌افتد؟

هیچ Referer در درخواست ارائه‌دهنده پرداخت HTTPS قابل مشاهده نیست، زیرا اکثر مرورگرها به‌طور پیش‌فرض زمانی که یک وب‌سایت فاقد خط‌مشی تنظیم شده است، از strict-origin-when-cross-origin یا no-referrer-when-downgrade استفاده می‌کنند، استفاده می‌کنند. تغییر Chrome به یک خط‌مشی پیش‌فرض جدید، این رفتار را تغییر نمی‌دهد.

نتیجه گیری

خط‌مشی ارجاع‌دهنده حفاظتی راهی عالی برای دادن حریم خصوصی بیشتر به کاربرانتان است.

برای کسب اطلاعات بیشتر در مورد تکنیک های مختلف برای محافظت از کاربران خود، به مجموعه ایمن و ایمن ما مراجعه کنید

منابع

• درک "همان سایت" و "همان منبع"
• عنوان امنیتی جدید: Referrer Policy (2017)
• Referrer-Policy در MDN
• سرصفحه ارجاع: نگرانی های حفظ حریم خصوصی و امنیتی در MDN
• تغییر کروم: پلک زدن قصد پیاده سازی
• تغییر کروم: پلک زدن قصد ارسال
• تغییر کروم: ورود وضعیت
• تغییر کروم: پست وبلاگ بتای 85
• پیوند ارجاع دهنده رشته GitHub: کاری که مرورگرهای مختلف انجام می دهند
• Referrer-Policy Spec

با تشکر فراوان برای مشارکت و بازخورد به همه داوران - به ویژه Kaustubha Govind، David Van Cleve، Mike West، Sam Dutton، Rowan Merewood، Jxck، و Kayce Basques.