جداسازی سایت برای توسعه دهندگان وب

ماتیاس بیننس

Chrome 67 روی دسکتاپ دارای ویژگی جدیدی به نام Site Isolation است که به طور پیش فرض فعال شده است . این مقاله توضیح می دهد که جداسازی سایت چیست، چرا لازم است، و چرا توسعه دهندگان وب باید از آن آگاه باشند.

جداسازی سایت چیست؟

اینترنت برای تماشای ویدیوهای گربه‌ها و مدیریت کیف پول‌های ارزهای دیجیتال، از جمله چیزهای دیگر است - اما شما نمی‌خواهید fluffycats.example به رمزارزهای ارزشمند شما دسترسی داشته باشد! خوشبختانه، وب‌سایت‌ها معمولاً نمی‌توانند به داده‌های یکدیگر در داخل مرورگر به لطف سیاست همان منبع دسترسی داشته باشند. با این حال، وب‌سایت‌های مخرب ممکن است سعی کنند این خط‌مشی را برای حمله به وب‌سایت‌های دیگر دور بزنند، و گاهی اوقات، اشکالات امنیتی در کد مرورگر یافت می‌شوند که خط‌مشی همان منبع را اجرا می‌کند. هدف تیم کروم این است که چنین اشکالاتی را در سریع ترین زمان ممکن برطرف کند.

Site Isolation یک ویژگی امنیتی در کروم است که یک خط دفاعی اضافی را ارائه می دهد تا احتمال موفقیت چنین حملاتی کاهش یابد. این تضمین می‌کند که صفحات از وب‌سایت‌های مختلف همیشه در فرآیندهای متفاوتی قرار می‌گیرند، هر کدام در یک جعبه ایمنی اجرا می‌شوند که اجازه انجام این فرآیند را محدود می‌کند. همچنین فرآیند را از دریافت انواع خاصی از داده های حساس از سایت های دیگر مسدود می کند. در نتیجه، با Site Isolation، برای یک وب سایت مخرب استفاده از حملات احتمالی کانال جانبی مانند Spectre برای سرقت داده ها از سایت های دیگر بسیار دشوارتر است. همانطور که تیم Chrome اقدامات دیگر را تکمیل می کند، Site Isolation نیز کمک خواهد کرد حتی زمانی که صفحه مهاجم بتواند برخی از قوانین را در فرآیند خودش زیر پا بگذارد.

Site Isolation به طور مؤثر دسترسی وب سایت های نامعتبر یا سرقت اطلاعات از حساب های شما در سایر وب سایت ها را دشوارتر می کند. محافظت بیشتری در برابر انواع مختلف باگ های امنیتی، مانند حملات اخیر کانال جانبی Meltdown و Spectre ارائه می دهد.

برای جزئیات بیشتر در مورد جداسازی سایت، به مقاله ما در وبلاگ امنیت Google مراجعه کنید.

Cross-Origin Read Blocking

حتی زمانی که همه صفحات بین سایتی در فرآیندهای جداگانه قرار می گیرند، صفحات همچنان می توانند به طور قانونی برخی منابع فرعی بین سایتی مانند تصاویر و جاوا اسکریپت را درخواست کنند. یک صفحه وب مخرب می تواند از عنصر <img> برای بارگیری یک فایل JSON با داده های حساس مانند موجودی بانک شما استفاده کند:

<img src="https://your-bank.example/balance.json" />
<!-- Note: the attacker refused to add an `alt` attribute, for extra evil points. -->

بدون Site Isolation، محتویات فایل JSON به حافظه فرآیند رندر می‌رسد، در این مرحله رندر متوجه می‌شود که فرمت تصویر معتبر نیست و تصویری را ارائه نمی‌کند. اما مهاجم می‌تواند از آسیب‌پذیری مانند Spectre برای خواندن بالقوه آن حافظه استفاده کند.

به جای استفاده از <img> ، مهاجم همچنین می تواند از <script> برای تخصیص داده های حساس به حافظه استفاده کند:

<script src="https://your-bank.example/balance.json"></script>

Cross-Origin Read Blocking یا CORB یک ویژگی امنیتی جدید است که از ورود محتویات balance.json به حافظه پردازش رندر بر اساس نوع MIME آن جلوگیری می کند.

بیایید نحوه عملکرد CORB را بررسی کنیم. یک وب سایت می تواند دو نوع منبع از یک سرور درخواست کند:

  1. منابع داده مانند اسناد HTML، XML یا JSON
  2. منابع رسانه ای مانند تصاویر، جاوا اسکریپت، CSS یا فونت ها

یک وب‌سایت می‌تواند منابع داده را از مبدا خود یا از مبداهای دیگر با هدرهای مجاز CORS مانند Access-Control-Allow-Origin: * . از سوی دیگر، منابع رسانه ای را می توان از هر منبعی، حتی بدون هدرهای مجاز CORS، گنجاند.

CORB از دریافت یک منبع داده متقاطع (مانند HTML، XML یا JSON) در فرآیند رندر جلوگیری می‌کند:

  • این منبع دارای یک هدر X-Content-Type-Options: nosniff
  • CORS به صراحت اجازه دسترسی به منبع را نمی دهد

اگر منبع داده متقاطع دارای X-Content-Type-Options: nosniff هدر نباشد، CORB تلاش می کند بدنه پاسخ را بشنود تا تعیین کند که آیا HTML، XML یا JSON است. این امر ضروری است زیرا برخی از سرورهای وب اشتباه پیکربندی شده اند و برای مثال تصاویر را به صورت text/html ارائه می کنند.

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

برای امنیت مطلوب و بهره مندی از CORB، موارد زیر را توصیه می کنیم:

  • پاسخ ها را با هدر Content-Type درست علامت گذاری کنید. (به عنوان مثال، منابع HTML باید به عنوان text/html ، منابع JSON با نوع JSON MIME و منابع XML با نوع XML MIME ارائه شوند).
  • با استفاده از هدر X-Content-Type-Options: nosniff از sniffing خودداری کنید. بدون این هدر، کروم یک تجزیه و تحلیل محتوای سریع انجام می‌دهد تا تأیید کند که نوع آن درست است، اما از آنجایی که این اشتباه در اجازه دادن به پاسخ‌ها برای جلوگیری از مسدود کردن مواردی مانند فایل‌های جاوا اسکریپت است، بهتر است به طور مثبت کار درست را انجام دهید. خودت

برای جزئیات بیشتر، به مقاله CORB برای توسعه دهندگان وب یا توضیح عمیق CORB ما مراجعه کنید.

چرا توسعه دهندگان وب باید به جداسازی سایت اهمیت دهند؟

در بیشتر موارد، Site Isolation یک ویژگی مرورگر پشت صحنه است که مستقیماً در معرض توسعه دهندگان وب قرار نمی گیرد. به عنوان مثال، هیچ API جدیدی برای یادگیری در معرض وب وجود ندارد. به طور کلی، صفحات وب نباید هنگام اجرا با Site Isolation یا بدون آن، تفاوت را تشخیص دهند.

با این حال، استثناهایی برای این قاعده وجود دارد. فعال کردن Site Isolation با چند اثر جانبی ظریف همراه است که ممکن است بر وب سایت شما تأثیر بگذارد. ما فهرستی از مسائل شناخته شده ایزوله سازی سایت را نگه می داریم و مهمترین آنها را در زیر توضیح می دهیم.

طرح بندی تمام صفحه دیگر همزمان نیست

با Site Isolation، طرح بندی تمام صفحه دیگر تضمین نمی شود که همزمان باشد، زیرا فریم های یک صفحه ممکن است اکنون در چندین فرآیند پخش شوند. این ممکن است بر صفحات تأثیر بگذارد اگر آنها فرض کنند که یک تغییر طرح بلافاصله به همه فریم های صفحه منتشر می شود.

به عنوان مثال، بیایید وب‌سایتی به نام fluffykittens.example را در نظر بگیریم که با ویجت اجتماعی میزبانی شده در social-widget.example ارتباط برقرار می‌کند:

<!-- https://fluffykittens.example/ -->
<iframe src="https://social-widget.example/" width="123"></iframe>
<script>
  const iframe = document.querySelector('iframe');
  iframe.width = 456;
  iframe.contentWindow.postMessage(
    // The message to send:
    'Meow!',
    // The target origin:
    'https://social-widget.example'
  );
</script>

در ابتدا، عرض <iframe> ویجت اجتماعی 123 پیکسل است. اما سپس، صفحه FluffyKittens عرض را به 456 پیکسل تغییر می‌دهد (طرح‌بندی فعال) و پیامی را به ویجت اجتماعی ارسال می‌کند که دارای کد زیر است:

<!-- https://social-widget.example/ -->
<script>
  self.onmessage = () => {
    console.log(document.documentElement.clientWidth);
  };
</script>

هر زمان که ویجت اجتماعی پیامی را از طریق postMessage API دریافت می کند، عرض عنصر ریشه <html> خود را ثبت می کند.

کدام مقدار عرض ثبت می شود؟ قبل از اینکه Chrome Site Isolation را فعال کند، پاسخ 456 بود. دسترسی به document.documentElement.clientWidth چیدمان را مجبور می‌کند، که قبل از فعال کردن Chrome Site Isolation همزمان بود. با این حال، با فعال کردن Site Isolation، طرح بندی مجدد ویجت اجتماعی متقاطع اکنون به صورت ناهمزمان در یک فرآیند جداگانه انجام می شود. به این ترتیب، اکنون پاسخ می تواند 123 باشد، یعنی مقدار width قدیمی.

اگر صفحه ای اندازه یک <iframe> با مبدا متقاطع را تغییر دهد و سپس یک postMessage برای آن ارسال کند، با Site Isolation، فریم دریافت کننده ممکن است هنوز اندازه جدید خود را هنگام دریافت پیام ندانند. به طور کلی‌تر، اگر فرض کنند که تغییر طرح فوراً در تمام فریم‌های صفحه منتشر می‌شود، ممکن است صفحات را بشکند.

در این مثال خاص، یک راه‌حل قوی‌تر، width در قاب والد تنظیم می‌کند و با گوش دادن به رویداد resize آن تغییر را در <iframe> تشخیص می‌دهد.

کنترل‌کننده‌های بارگیری ممکن است بیشتر وقت‌ها به اتمام برسد

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

addEventListener('unload', () => {
  doSomethingThatMightTakeALongTime();
});

در این شرایط، دسته های unload در همه فریم ها بسیار قابل اعتماد هستند.

با این حال، حتی بدون جداسازی سایت، برخی از پیمایش‌های فریم اصلی متقاطع هستند، که بر رفتار کنترل کننده بارگیری تأثیر می‌گذارد. برای مثال، اگر از old.example به new.example با تایپ URL در نوار آدرس پیمایش کنید، پیمایش new.example در یک فرآیند جدید اتفاق می‌افتد. کنترل‌کننده‌های تخلیه برای old.example و فریم‌های فرعی آن در فرآیند old.example در پس‌زمینه، پس از نمایش صفحه new.example اجرا می‌شوند، و کنترل‌کننده‌های تخلیه قدیمی در صورتی که در مدت زمان مشخصی به پایان نرسند، خاتمه می‌یابند . از آنجایی که کنترل کننده های تخلیه ممکن است قبل از اتمام زمان تمام نشوند، رفتار تخلیه کمتر قابل اعتماد است.

با Site Isolation، تمام پیمایش های بین سایتی تبدیل به فرآیند متقابل می شوند، به طوری که اسناد سایت های مختلف فرآیندی را با یکدیگر به اشتراک نمی گذارند. در نتیجه، وضعیت فوق در موارد بیشتری اعمال می‌شود و کنترل‌کننده‌های تخلیه بار در <iframe> اغلب رفتارهای پس‌زمینه و زمان‌بندی توضیح داده شده در بالا را دارند.

یکی دیگر از تفاوت‌های حاصل از Site Isolation، ترتیب موازی جدید کنترل‌کننده‌های تخلیه است: بدون Site Isolation، کنترل‌کننده‌های تخلیه بار به‌ترتیب دقیق از بالا به پایین در فریم‌ها اجرا می‌شوند. اما با Site Isolation، unload handlerها به صورت موازی در بین فرآیندهای مختلف اجرا می شوند.

اینها پیامدهای اساسی فعال کردن Site Isolation هستند. تیم Chrome در حال کار بر روی بهبود قابلیت اطمینان کنترل‌کننده‌های تخلیه بار برای موارد استفاده رایج، در صورت امکان، است. ما همچنین از اشکالاتی آگاه هستیم که در آن کنترل‌کننده‌های تخلیه فریم فریم هنوز قادر به استفاده از ویژگی‌های خاص نیستند و در تلاش برای رفع آنها هستند.

یک مورد مهم برای unload handlerها ارسال پینگ پایان جلسه است. این معمولاً به صورت زیر انجام می شود:

addEventListener('pagehide', () => {
  const image = new Image();
  img.src = '/end-of-session';
});

یک رویکرد بهتر که با توجه به این تغییر قوی تر است، استفاده از navigator.sendBeacon به جای آن است:

addEventListener('pagehide', () => {
  navigator.sendBeacon('/end-of-session');
});

اگر به کنترل بیشتری روی درخواست نیاز دارید، می‌توانید از گزینه keepalive Fetch API استفاده کنید:

addEventListener('pagehide', () => {
  fetch('/end-of-session', {keepalive: true});
});

نتیجه گیری

Site Isolation با جداسازی هر سایت در فرآیند خودش، دسترسی یا سرقت اطلاعات از حساب‌های شما در سایر وب‌سایت‌ها را برای وب‌سایت‌های غیرقابل اعتماد دشوارتر می‌کند. به عنوان بخشی از آن، CORB سعی می کند منابع داده حساس را از فرآیند رندر دور نگه دارد. توصیه‌های ما در بالا تضمین می‌کند که بیشترین بهره را از این ویژگی‌های امنیتی جدید ببرید.

با تشکر از الکس موشچوک، چارلی ریس، جیسون میلر، ناسکو اسکوف، فیلیپ والتون، شوبی پانیکر و توماس اشتاینر برای خواندن نسخه پیش نویس این مقاله و ارائه بازخورد خود.