یک خط‌مشی پیش‌فرض ارجاع‌دهنده جدید برای Chrome - strict-origin-when-cross-origin

قبل از شروع:

  • اگر از تفاوت بین «site» و «origin» مطمئن نیستید، به بخش «درک تفاوت‌های same-site» و «same-origin» مراجعه کنید.
  • هدر Referer به دلیل غلط املایی اولیه در مشخصات، فاقد R است. هدر Referrer-Policy و referrer در جاوا اسکریپت و DOM به درستی نوشته شده‌اند.

خلاصه

  • مرورگرها در حال تکامل به سمت سیاست‌های ارجاع پیش‌فرض برای افزایش حریم خصوصی هستند تا در مواقعی که وب‌سایتی هیچ سیاستی ندارد، جایگزین خوبی ارائه دهند.
  • کروم قصد دارد به تدریج strict-origin-when-cross-origin به عنوان سیاست پیش‌فرض در نسخه ۸۵ فعال کند؛ این امر ممکن است بر موارد استفاده‌ای که به مقدار ارجاع از یک مبدأ دیگر متکی هستند، تأثیر بگذارد.
  • این پیش‌فرض جدید است، اما وب‌سایت‌ها هنوز می‌توانند سیاست دلخواه خود را انتخاب کنند.
  • برای امتحان کردن این تغییر در کروم، پرچم (flags) را در chrome://flags/#reduced-referrer-granularity فعال کنید. همچنین می‌توانید این نسخه آزمایشی را بررسی کنید تا تغییر را در عمل ببینید.
  • فراتر از سیاست ارجاع، نحوه برخورد مرورگرها با ارجاع‌دهندگان ممکن است تغییر کند—پس مراقب آن باشید.

چه چیزی در حال تغییر است و چرا؟

درخواست‌های HTTP ممکن است شامل سربرگ اختیاری Referer باشند که نشان دهنده‌ی مبدأ یا URL صفحه‌ی وبی است که درخواست از آن ارسال شده است. سربرگ Referer-Policy مشخص می‌کند که چه داده‌هایی در سربرگ Referer و برای ناوبری و iframeها در document.referrer مقصد در دسترس قرار می‌گیرند.

اینکه دقیقاً چه اطلاعاتی در هدر Referer در یک درخواست از سایت شما ارسال می‌شود، توسط هدر Referrer-Policy که تنظیم می‌کنید، تعیین می‌شود.

نمودار: ارجاع‌دهنده درخواستی ارسال کرده است.
سیاست ارجاع و ارجاع دهنده.

وقتی هیچ سیاستی تنظیم نشده باشد، از پیش‌فرض مرورگر استفاده می‌شود. وب‌سایت‌ها اغلب از پیش‌فرض مرورگر پیروی می‌کنند.

برای پیمایش‌ها و iframeها، داده‌های موجود در سربرگ Referer را می‌توان از طریق جاوا اسکریپت با استفاده از document.referrer نیز دسترسی پیدا کرد.

تا همین اواخر، no-referrer-when-downgrade یک سیاست پیش‌فرض گسترده در بین مرورگرها بود. اما اکنون بسیاری از مرورگرها در مرحله‌ای از حرکت به سمت پیش‌فرض‌های تقویت‌کننده حریم خصوصی هستند.

کروم قصد دارد از نسخه ۸۵ به بعد ، سیاست پیش‌فرض خود را از no-referrer-when-downgrade به strict-origin-when-cross-origin تغییر دهد.

این بدان معناست که اگر هیچ سیاستی برای وب‌سایت شما تنظیم نشده باشد، کروم به‌طور پیش‌فرض از strict-origin-when-cross-origin استفاده خواهد کرد. توجه داشته باشید که همچنان می‌توانید سیاست دلخواه خود را تنظیم کنید؛ این تغییر فقط روی وب‌سایت‌هایی که هیچ سیاستی تنظیم نکرده‌اند، تأثیر خواهد گذاشت.

این تغییر به چه معناست؟

strict-origin-when-cross-origin حریم خصوصی بیشتری ارائه می‌دهد. با این سیاست، فقط مبدا در هدر Referer درخواست‌های cross-origin ارسال می‌شود.

این کار از نشت داده‌های خصوصی که ممکن است از سایر بخش‌های URL کامل مانند مسیر و رشته پرس‌وجو قابل دسترسی باشند، جلوگیری می‌کند.

نمودار: ارجاع‌دهنده‌ای که بسته به سیاست، برای یک درخواست بین‌مرجعی ارسال شده است.
بسته به سیاست، Referer (و document.referrer) برای یک درخواست بین مبدا ارسال شد.

برای مثال:

درخواست بین مبدا، ارسال شده از https://site-one.example/ stuff/detail?tag=red به https://site-two.example/…:

  • با no-referrer-when-downgrade : ارجاع دهنده: https://site-one.example/ stuff/detail?tag=red .
  • با strict-origin-when-cross-origin : ارجاع دهنده: https://site-one.example/.

چه چیزی ثابت می‌ماند؟

  • مانند no-referrer-when-downgrade ، strict-origin-when-cross-origin نیز امن است: هیچ ارجاع‌دهنده‌ای (سربرگ Referer و document.referrer ) هنگام ارسال درخواست از مبدا HTTPS (امن) به مبدا HTTP (ناامن) وجود ندارد. به این ترتیب، اگر وب‌سایت شما از HTTPS استفاده می‌کند ( اگر نه، آن را در اولویت قرار دهید )، URLهای وب‌سایت شما در درخواست‌های غیر HTTPS نشت نمی‌کنند - زیرا هر کسی در شبکه می‌تواند این موارد را ببیند، بنابراین این امر کاربران شما را در معرض حملات مرد میانی قرار می‌دهد.
  • در همان مبدا، مقدار هدر Referer ، آدرس کامل URL است.

برای مثال: درخواست Same-origin، ارسال شده از https://site-one.example/ stuff/detail?tag=red به https://site-one.example/…:

  • با strict-origin-when-cross-origin : ارجاع دهنده: https://site-one.example/ stuff/detail?tag=red

چه تاثیری دارد؟

بر اساس بحث و گفتگو با سایر مرورگرها و آزمایش‌های خود کروم در کروم ۸۴، انتظار می‌رود که خرابی‌های قابل مشاهده توسط کاربر محدود باشد .

گزارش‌گیری یا تحلیل‌های سمت سرور که به در دسترس بودن آدرس اینترنتی کامل ارجاع‌دهنده متکی هستند، احتمالاً تحت تأثیر کاهش جزئیات در آن اطلاعات قرار خواهند گرفت.

چه کاری باید انجام دهید؟

کروم قصد دارد سیاست جدید ارجاع پیش‌فرض را در سال ۸۵ (ژوئیه ۲۰۲۰ برای نسخه بتا، اوت ۲۰۲۰ برای نسخه پایدار) اجرا کند. وضعیت را در ورودی وضعیت کروم مشاهده کنید.

تغییر را درک و تشخیص دهید

برای درک اینکه پیش‌فرض جدید در عمل چه تغییراتی ایجاد می‌کند، می‌توانید این نسخه آزمایشی را بررسی کنید.

همچنین می‌توانید از این نسخه آزمایشی برای تشخیص اینکه چه سیاستی در نمونه کرومی که اجرا می‌کنید اعمال شده است، استفاده کنید.

تغییر را آزمایش کنید و ببینید آیا این تغییر روی سایت شما تأثیر می‌گذارد یا خیر.

شما می‌توانید این تغییر را از کروم ۸۱ امتحان کنید: در کروم به آدرس chrome://flags/#reduced-referrer-granularity مراجعه کنید و این پرچم را فعال کنید. وقتی این پرچم فعال شود، همه وب‌سایت‌های بدون خط‌مشی از پیش‌فرض جدید strict-origin-when-cross-origin استفاده خواهند کرد.

تصویر کروم: نحوه فعال کردن فلگ chrome://flags/#reduced-referrer-granularity.
فعال کردن پرچم.

اکنون می‌توانید نحوه رفتار وب‌سایت و بک‌اند خود را بررسی کنید.

کار دیگری که برای تشخیص تأثیر باید انجام دهید این است که بررسی کنید آیا کدبیس وب‌سایت شما از ارجاع‌دهنده استفاده می‌کند یا خیر - چه از طریق سربرگ Referer درخواست‌های ورودی روی سرور و چه از document.referrer در جاوااسکریپت.

اگر از ارجاع‌دهنده‌ی درخواست‌ها از مبدا دیگری به سایت خود (به‌طور خاص مسیر و/یا رشته‌ی پرس‌وجو) استفاده می‌کنید و این مبدا از سیاست ارجاع پیش‌فرض مرورگر استفاده می‌کند (یعنی هیچ سیاستی تنظیم نشده است)، ممکن است برخی از ویژگی‌های سایت شما خراب شوند یا رفتار متفاوتی داشته باشند.

اگر این موضوع روی سایت شما تأثیر می‌گذارد، گزینه‌های دیگری را در نظر بگیرید

اگر از ارجاع‌دهنده برای دسترسی به مسیر کامل یا رشته پرس‌وجوی درخواست‌ها به سایت خود استفاده می‌کنید، چند گزینه دارید:

  • از تکنیک‌ها و هدرهای جایگزین مانند Origin و Sec-fetch-Site برای محافظت در برابر CSRF، ثبت وقایع و سایر موارد استفاده استفاده کنید. به Referer و Referrer-Policy: best practiceها مراجعه کنید.
  • اگر لازم باشد و برای کاربرانتان شفاف باشد، می‌توانید با شرکا در مورد یک سیاست خاص هماهنگ شوید. کنترل دسترسی - زمانی که ارجاع‌دهنده توسط وب‌سایت‌ها برای اعطای دسترسی خاص به منابعشان به سایر مبدأها استفاده می‌شود - ممکن است چنین موردی باشد، اگرچه با تغییر کروم، مبدأ همچنان در سربرگ Referer (و در document.referrer ) به اشتراک گذاشته خواهد شد.

توجه داشته باشید که اکثر مرورگرها در مورد ارجاع‌دهنده (referrer) در جهت مشابهی حرکت می‌کنند (به پیش‌فرض‌های مرورگر و تکامل آنها در Referrer و Referrer-Policy: best practiceها مراجعه کنید).

یک سیاست صریح و شفاف برای افزایش حریم خصوصی در سراسر سایت خود اجرا کنید

چه Referer باید در درخواست‌های ارسالی از وب‌سایت شما ارسال شود، یعنی چه سیاستی باید برای سایت خود تعیین کنید؟

حتی با وجود تغییر در نظر گرفته شده توسط کروم، ایده خوبی است که همین الان یک سیاست صریح و تقویت‌کننده حریم خصوصی مانند strict-origin-when-cross-origin یا stricter تنظیم کنید.

این کار از کاربران شما محافظت می‌کند و باعث می‌شود وب‌سایت شما در مرورگرهای مختلف، رفتار قابل پیش‌بینی‌تری داشته باشد. در واقع، به شما کنترل می‌دهد - به جای اینکه سایت شما به پیش‌فرض‌های مرورگر وابسته باشد.

برای جزئیات بیشتر در مورد تنظیم یک سیاست، به Referrer و Referrer-Policy: best practiceها مراجعه کنید.

درباره کروم اینترپرایز

سیاست سازمانی Chrome ForceLegacyDefaultReferrerPolicy در دسترس مدیران فناوری اطلاعات است که می‌خواهند سیاست ارجاع پیش‌فرض قبلی یعنی no-referrer-when-downgrade در محیط‌های سازمانی اعمال کنند. این امر به شرکت‌ها زمان بیشتری برای آزمایش و به‌روزرسانی برنامه‌های خود می‌دهد.

این خط‌مشی در کروم ۸۸ حذف خواهد شد.

ارسال بازخورد

آیا بازخوردی برای به اشتراک گذاشتن یا گزارش چیزی دارید؟ بازخورد خود را در مورد قصد عرضه کروم به اشتراک بگذارید، یا سوالات خود را در @maudnals توییت کنید.

با تشکر فراوان از همه داوران - به ویژه کاستوبا گوویند، دیوید ون کلیو، مایک وست، سم داتون، روآن مروود، جکسک و کیس باسک - به خاطر مشارکت‌ها و بازخوردهایشان.

منابع