چرا به «منشا متقاطع ایزوله شده نیاز دارید» برای ویژگی های قدرتمند

بیاموزید که چرا برای استفاده از ویژگی‌های قدرتمندی مانند SharedArrayBuffer ، performance.measureUserAgentSpecificMemory() و تایمر با وضوح بالا و دقت بهتر، به جداسازی بین مبدا (cross-origin isolation) نیاز است.

Eiji Kitamura

Domenic Denicola

مقدمه

در «ایزوله‌سازی متقابل مبدأ» وب‌سایت خود با استفاده از COOP و COEP، نحوه‌ی تطبیق با حالت «ایزوله‌سازی متقابل مبدأ» را با استفاده از COOP و COEP توضیح دادیم. این یک مقاله‌ی همراه است که توضیح می‌دهد چرا ایزولاسیون متقابل مبدأ برای فعال کردن ویژگی‌های قدرتمند در مرورگر مورد نیاز است.

پیشینه

وب بر اساس سیاست same-origin ساخته شده است: یک ویژگی امنیتی که نحوه تعامل اسناد و اسکریپت‌ها با منابع از مبدا دیگر را محدود می‌کند. این اصل، روش‌های دسترسی وب‌سایت‌ها به منابع بین مبدایی را محدود می‌کند. به عنوان مثال، از دسترسی یک سند از https://a.example به داده‌های میزبانی شده در https://b.example جلوگیری می‌شود.

با این حال، سیاست same-origin استثنائاتی در طول تاریخ داشته است. هر وب‌سایتی می‌تواند:

• جاسازی آی‌فریم‌های کراس-اوریجین
• منابع بین‌منبعی مانند تصاویر یا اسکریپت‌ها را در نظر بگیرید
• پنجره‌های پاپ‌آپ بین مبدا و مقصد را با ارجاع DOM باز کنید

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

عوارض جانبی امنیتی چنین سیاست سهل‌انگارانه‌ای در مورد منابع یکسان، به دو روش اصلاح شد. یک راه از طریق معرفی پروتکل جدیدی به نام Cross Origin Resource Sharing (CORS) بود که هدف آن اطمینان از این است که سرور اجازه اشتراک‌گذاری منبع با یک منبع مشخص را می‌دهد. راه دیگر، حذف ضمنی دسترسی مستقیم اسکریپت به منابع cross-origin با حفظ سازگاری با نسخه‌های قبلی است. به چنین منابع cross-origin، منابع "مات" گفته می‌شود. به عنوان مثال، به همین دلیل است که دستکاری پیکسل‌های یک تصویر cross-origin از طریق CanvasRenderingContext2D بدون اعمال CORS به تصویر، با شکست مواجه می‌شود.

همه این تصمیمات مربوط به سیاست‌ها در یک گروه زمینه مرور اتفاق می‌افتد.

برای مدت طولانی، ترکیب CORS و منابع غیرشفاف برای ایمن‌سازی مرورگرها کافی بود. گاهی اوقات موارد حاشیه‌ای (مانند آسیب‌پذیری‌های JSON ) کشف می‌شدند و نیاز به وصله داشتند، اما در کل، اصل عدم اجازه دسترسی مستقیم به بایت‌های خام منابع بین‌مربعی موفقیت‌آمیز بود.

همه این‌ها با Spectre تغییر کرد، که هر داده‌ای را که در همان گروه زمینه مرور مانند کد شما بارگذاری می‌شود، به طور بالقوه قابل خواندن می‌کند. با اندازه‌گیری زمانی که عملیات خاص طول می‌کشد، مهاجمان می‌توانند محتویات حافظه پنهان CPU و از طریق آن، محتویات حافظه فرآیند را حدس بزنند. چنین حملات زمان‌بندی با تایمرهای با دانه‌بندی کم که در پلتفرم وجود دارند، امکان‌پذیر است، اما می‌توان آن‌ها را با تایمرهای با دانه‌بندی بالا، چه صریح (مانند performance.now() ) و چه ضمنی (مانند SharedArrayBuffer ) تسریع کرد. اگر evil.com یک تصویر با منشأ متقابل را جاسازی کند، می‌تواند از حمله Spectre برای خواندن داده‌های پیکسلی آن استفاده کند، که باعث می‌شود محافظت‌های متکی بر "مات بودن" بی‌اثر شوند.

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

تحت حالت ایزوله‌سازی بین مبدا، سایت درخواست‌کننده کمتر خطرناک در نظر گرفته می‌شود و این امر ویژگی‌های قدرتمندی مانند SharedArrayBuffer ، performance.measureUserAgentSpecificMemory() و تایمرهای با وضوح بالا با دقت بهتر را فعال می‌کند که در غیر این صورت می‌توانستند برای حملات شبه‌اسپکتر استفاده شوند. همچنین از تغییر document.domain جلوگیری می‌کند.

سیاست جاسازی متقابل مبدا

سیاست جاسازی متقابل منبع (COEP) مانع از بارگیری هرگونه منبع متقابل منبعی می‌شود که صریحاً مجوز سند را اعطا نمی‌کنند (با استفاده از CORP یا CORS). با این ویژگی، می‌توانید اعلام کنید که یک سند نمی‌تواند چنین منابعی را بارگیری کند.

برای فعال کردن این خط‌مشی، هدر HTTP زیر را به سند اضافه کنید:

Cross-Origin-Embedder-Policy: require-corp

COEP یک مقدار واحد به نام require-corp می‌گیرد. این سیاست را اعمال می‌کند که سند فقط می‌تواند منابعی را از همان مبدأ یا منابعی را که به صراحت به عنوان قابل بارگیری از مبدأ دیگری علامت‌گذاری شده‌اند، بارگیری کند.

برای اینکه منابع از مبدا دیگری قابل بارگیری باشند، باید از اشتراک‌گذاری منابع بین مبدایی (CORS) یا سیاست منابع بین مبدایی (CORP) پشتیبانی کنند.

اشتراک‌گذاری منابع بین‌منشأیی

اگر یک منبع بین‌منبعی از اشتراک‌گذاری منابع بین‌منبعی (CORS) پشتیبانی کند، می‌توانید از ویژگی crossorigin برای بارگذاری آن در صفحه وب خود بدون مسدود شدن توسط COEP استفاده کنید.

<img src="https://third-party.example.com/image.jpg" crossorigin>

برای مثال، اگر این منبع تصویر با هدرهای CORS ارائه می‌شود، از ویژگی crossorigin استفاده کنید تا درخواست برای دریافت منبع از حالت CORS استفاده کند. این کار همچنین از بارگیری تصویر جلوگیری می‌کند مگر اینکه هدرهای CORS را تنظیم کند.

به طور مشابه، می‌توانید داده‌های بین مبدا (cross origin) را از طریق متد fetch() دریافت کنید، که تا زمانی که سرور با هدرهای HTTP مناسب پاسخ دهد، نیازی به مدیریت خاصی ندارد.

سیاست منابع بین‌منبعی

سیاست منابع بین مبدایی (CORP) در ابتدا به عنوان یک گزینه اختیاری برای محافظت از منابع شما در برابر بارگیری توسط مبدا دیگر معرفی شد. در زمینه COEP، CORP می‌تواند سیاست مالک منبع را برای اینکه چه کسی می‌تواند یک منبع را بارگیری کند، مشخص کند.

هدر Cross-Origin-Resource-Policy سه مقدار ممکن را می‌پذیرد:

Cross-Origin-Resource-Policy: same-site

منابعی که با عنوان same-site علامت‌گذاری شده‌اند، فقط می‌توانند از همان سایت بارگیری شوند.

Cross-Origin-Resource-Policy: same-origin

منابعی که با عنوان same-origin علامت‌گذاری شده‌اند، فقط می‌توانند از همان مبدأ بارگیری شوند.

Cross-Origin-Resource-Policy: cross-origin

منابعی که با علامت cross-origin مشخص شده‌اند، می‌توانند توسط هر وب‌سایتی بارگذاری شوند. ( این مقدار به همراه COEP به مشخصات CORP اضافه شده است.)

سیاست افتتاحیه کراس اوریجین

سیاست بازکننده‌ی متقابل (COOP) به شما این امکان را می‌دهد که با قرار دادن یک پنجره‌ی سطح بالا در یک گروه زمینه‌ی مرور متفاوت، از ایزوله بودن آن از سایر اسناد اطمینان حاصل کنید، به طوری که آنها نتوانند مستقیماً با پنجره‌ی سطح بالا تعامل داشته باشند. به عنوان مثال، اگر سندی با COOP یک پنجره‌ی بازشو باز کند، ویژگی window.opener آن null خواهد بود. همچنین، ویژگی .closed مربوط به ارجاع بازکننده به آن، true برمی‌گرداند.

هدر Cross-Origin-Opener-Policy سه مقدار ممکن را می‌پذیرد:

Cross-Origin-Opener-Policy: same-origin

اسنادی که با علامت same-origin مشخص شده‌اند، می‌توانند گروه زمینه مرور یکسانی را با اسنادی که با علامت same-origin مشخص شده‌اند، به اشتراک بگذارند.

Cross-Origin-Opener-Policy: same-origin-allow-popups

یک سند سطح بالا با same-origin-allow-popups ارجاعات به هر یک از پاپ‌آپ‌های خود را که یا COOP را تنظیم نمی‌کنند یا با تنظیم COOP به مقدار unsafe-none از حالت ایزوله خارج می‌شوند، حفظ می‌کند.

Cross-Origin-Opener-Policy: unsafe-none

unsafe-none پیش‌فرض است و اجازه می‌دهد سند به گروه زمینه مرور بازکننده‌اش اضافه شود، مگر اینکه خود بازکننده دارای COOP با same-origin باشد.

خلاصه

If you want guaranteed access to powerful features like SharedArrayBuffer , performance.measureUserAgentSpecificMemory() or high resolution timers with better precision, just remember that your document needs to use both COEP with the value of require-corp and COOP with the value of same-origin . In the absence of either, the browser will not guarantee sufficient isolation to safely enable those powerful features. You can determine your page's situation by checking if self.crossOriginIsolated returns true .

مراحل پیاده‌سازی این مورد را در «ایزوله‌سازی متقابل وب‌سایت» با استفاده از COOP و COEP بیاموزید.

منابع

• COOP و COEP توضیح داده شدند
• تغییرات برنامه‌ریزی‌شده در حافظه مشترک - جاوا اسکریپت | MDN