سیاست‌های توسعه‌دهندگان و دستورالعمل‌های امنیتی

سایمون هانگل
Simon Hangl
دمیان رنزولی
Demián Renzulli

برنامه‌های وب ایزوله (IWA) یک مدل امنیتی ارائه می‌دهند که به برنامه‌های وب اجازه می‌دهد به قابلیت‌های قدرتمندی - مانند سوکت‌های مستقیم و فریم کنترل‌شده - که معمولاً در وب استاندارد "drive-by" محدود شده‌اند، دسترسی داشته باشند. از آنجا که IWAها در یک محیط با اعتماد بالا فعالیت می‌کنند، باید به سیاست‌های امنیتی و حریم خصوصی سختگیرانه‌ای پایبند باشند. این دستورالعمل‌ها به گونه‌ای طراحی شده‌اند که با افزایش قدرت پلتفرم وب، کاربران ایمن بمانند و یکپارچگی محیط مرورگر حفظ شود.

مدل اعتماد IWA

هسته پلتفرم IWA بر اساس سیاست‌های فنی سختگیرانه‌ای ساخته شده است که توسعه‌دهندگان را مجبور به حفظ سطح بالایی از امنیت می‌کند. در حالی که برنامه‌های وب استاندارد به یک مدل مجوز انعطاف‌پذیر متکی هستند، IWAها به صورت رمزنگاری امضا شده و با استفاده از Web Bundles ارائه می‌شوند که امکان تأیید منشأ و یکپارچگی آنها را فراهم می‌کند.

در ازای این هویت تأیید شده، IWAها به APIهای ممتاز دسترسی پیدا می‌کنند. برای حفظ این اعتماد، توسعه‌دهندگان باید با رعایت سیاست‌های سختگیرانه‌تر - از جمله سیاست امنیتی محتوا (CSP) قوی و انواع قابل اعتماد - رویکردی مبتنی بر امنیت را دنبال کنند که ایمنی کاربر را حتی هنگام استفاده از قابلیت‌های قدرتمند تضمین می‌کند. این به این معنی است:

  • شفافیت: کاربران هرگز نباید از استفاده یک برنامه از APIهای ممتاز شگفت‌زده شوند.
  • حداقل امتیاز: برنامه‌ها فقط باید قابلیت‌های خاص مورد نیاز برای هدف تعیین‌شده خود را درخواست و استفاده کنند.
  • یکپارچگی ایستا: تمام منطق اجرایی باید درون بسته برنامه مستقل باشد تا امکان ممیزی امنیتی فراهم شود و از بارگذاری جانبی کدهای مخرب جلوگیری شود.

اگرچه IWAها شامل محافظت‌های داخلی قوی هستند - مانند یک سیاست امنیتی محتوا (CSP) سختگیرانه که از اجرای اسکریپت‌های خارجی جلوگیری می‌کند - محدودیت‌های فنی به تنهایی نمی‌توانند همه خطرات را کاهش دهند. حتی در یک محیط با اعتماد بالا، الگوهای پیاده‌سازی خاص یا انتخاب‌های توسعه‌دهنده می‌توانند ناخواسته ایمنی یا حریم خصوصی کاربر را به خطر بیندازند. این راهنما این سناریوهای محدود و سیاست‌های حاکم بر استفاده از APIهای ممتاز را تشریح می‌کند.

چرا این دستورالعمل‌ها مهم هستند؟

رعایت این سیاست‌ها فقط مربوط به انطباق نیست - بلکه مربوط به ایجاد یک اکوسیستم پایدار برای برنامه‌های کاربردی وب پیشرفته است. با پیروی از این دستورالعمل‌ها، شما اطمینان حاصل می‌کنید که برنامه شما:

  • جلوگیری از رگرسیون‌های امنیتی: با مستقل نگه داشتن منطق، از آسیب‌پذیری‌هایی مانند اسکریپت‌نویسی بین‌سایتی (XSS) و اجرای کد از راه دور جلوگیری می‌کند.
  • محافظت از حریم خصوصی کاربر: تضمین می‌کند که داده‌های حساس و دسترسی به سخت‌افزار فقط با قصد و نیت صریح کاربر و شفافیت انجام می‌شود.
  • تضمین طول عمر پلتفرم: به حفظ استانداردهای امنیتی بالای مورد نیاز برای پلتفرم IWA جهت ادامه گسترش مجموعه قابلیت‌های آن کمک می‌کند.

اصول اساسی

شفافیت و قصد کاربر

اساسی‌ترین قانون این است: کاربر را غافلگیر نکنید. رفتار برنامه شما باید با هدف اعلام‌شده و انتظارات کاربر همسو باشد.

  • در محدوده‌ی هدف بمانید : قابلیت‌هایی را که فراتر از هدف مشخص برنامه‌ی شما هستند، پیاده‌سازی نکنید.
  • حداقل حجم API: فقط مجموعه خاصی از APIهای IWA را که برای دستیابی به عملکرد اصلی برنامه شما ضروری هستند، درخواست و استفاده کنید.

بدون بارگذاری جانبی کد پویا

مدل امنیتی IWA به توانایی مدیران یا فروشنده مرورگر برای تأیید تمام منطق‌های اجرایی بستگی دارد. در نتیجه، بسته IWA شما باید مستقل باشد. این پلتفرم این امر را از طریق یک سیاست امنیتی محتوا (CSP) سختگیرانه اعمال می‌کند که اجرای مبتنی بر رشته مانند eval() و new Function() را مسدود می‌کند:

script-src 'self' 'wasm-unsafe-eval';
require-trusted-types-for 'script';

اگرچه CSP به 'wasm-unsafe-eval' اجازه می‌دهد تا از WebAssembly پشتیبانی کند، اما شما نباید از اصل این مرز امنیتی عبور کنید.

اعمال اکیداً ممنوعه

  • ارسال مفسرها برای کد از راه دور: شما نمی‌توانید یک مفسر کد (مثلاً پایتون یا لوا که به WASM کامپایل شده است) برای دانلود و اجرای اسکریپت‌های خارجی با استفاده از دسترسی ممتاز به شبکه مانند Direct Sockets قرار دهید.
  • منطق بارگذاری شده از راه دور: از سرویس ورکرها برای جاسازی کد بارگذاری شده از راه دور در مبدا IWA استفاده نکنید.
  • کد در مقابل داده: اگرچه دانلود داده‌ها (مانند JSON) مجاز است، دانلود هر کدی که قرار است تفسیر یا اجرا شود، نقض مستقیم خط‌مشی است.

اصل حداقل امتیاز

همیشه از کم‌قدرت‌ترین API که قادر به انجام یک کار است استفاده کنید. APIهای اختصاصی IWA با سطح دسترسی بالا هرگز نباید به عنوان میانبری برای دور زدن محدودیت‌های امنیتی یا درخواست‌های کاربر از APIهای وب استاندارد استفاده شوند. جدول زیر موارد استفاده رایج را شرح می‌دهد تا به شما در تصمیم‌گیری در مورد زمان استفاده از APIهای وب سنتی در مقابل قابلیت‌های اختصاصی IWA کمک کند:

وظیفه استفاده از API وب استاندارد (توصیه می‌شود) از API IWA با دسترسی ویژه (محدود) اجتناب کنید
دسترسی به هارد دیسک اکسترنال از رابط برنامه‌نویسی کاربردی دسترسی به سیستم فایل (File System Access API) برای ورودی/خروجی استاندارد فایل استفاده کنید. برای دسترسی به فضای ذخیره‌سازی از WebUSB نامحدود استفاده نکنید.
تعامل با کارت هوشمند از API کارت هوشمند استفاده کنید. از WebUSB نامحدود برای کارت‌های هوشمند استفاده نکنید.
ارتباط سریال دستگاه اگر WebSerial API برای دستگاه شما کافی است، از آن استفاده کنید. اگر WebSerial می‌تواند این کار را انجام دهد، از WebUSB نامحدود خودداری کنید.
جاسازی محتوای قابل اعتماد از یک <iframe> استاندارد استفاده کنید. <controlledframe> برای جاسازی ساده استفاده نکنید، مگر اینکه جداسازی لازم باشد.

دستورالعمل‌های خاص API

رابط‌های برنامه‌نویسی کاربردی IWA قابلیت‌های قدرتمندی را ارائه می‌دهند که معمولاً در مرورگر محدود شده‌اند. راهنمایی کلی این است که هرگز از این ویژگی‌های ممتاز به گونه‌ای استفاده نکنید که کاربران را غافلگیر کند یا اعتماد و داده‌های آنها را به خطر بیندازد.

API سوکت‌های مستقیم

رابط برنامه‌نویسی کاربردی Direct Sockets دسترسی خام TCP و UDP، از جمله دسترسی چندپخشی و شبکه محلی را فراهم می‌کند.

مجاز

  • پشتیبانی از پروتکل‌های سفارشی: اتصال به سرورهای راه دوری که از پروتکل‌های سفارشی استفاده می‌کنند و در حال حاضر هیچ API وب سطح بالاتری برای آنها وجود ندارد.
  • نگهداری سرویس‌های backend: اتصال به یک سرور از پیش تعریف‌شده و کدنویسی‌شده که به‌طور خاص برای سرویس‌های backend برنامه شما استفاده می‌شود.
  • کشف سخت‌افزارهای ضروری: دسترسی به شبکه محلی یا استفاده از چندپخشی برای کشف سخت‌افزارهای خاص و مرتبط که برای عملکرد برنامه ضروری هستند (برای مثال، یک برنامه ویرایش ویدیو که محل ذخیره‌سازی متصل به شبکه را پیدا می‌کند).

مجاز نیست

  • غافلگیر کردن کاربر: پیاده‌سازی دسترسی به شبکه‌ای که به وضوح توسط عملکرد اصلی برنامه توجیه نمی‌شود، مانند یک ویرایشگر متن که با دستگاه‌های شبکه محلی ارتباط برقرار می‌کند.
  • اسکن خودسرانه شبکه‌ها: انجام اسکن‌های گسترده شبکه محلی کاربر (برای مثال، اسکن پورت ۱۹۲.۱۶۸.۱.۰/۲۴) برای شناسایی کاربر یا کشف دستگاه‌های نامرتبط.
  • هدف قرار دادن دستگاه‌های محلی: تلاش برای بررسی، پیکربندی مجدد یا حمله به سایر دستگاه‌های موجود در شبکه محلی اکیداً ممنوع است.

API فریم کنترل‌شده

عنصر <controlledframe> امکان جاسازی و اصلاح محتوای بین‌مرجعی، از جمله تزریق اسکریپت و تغییر هدر را فراهم می‌کند.

مجاز

  • ساده‌سازی رابط‌های کاربری: تعبیه یک سرویس شخص ثالث و تزریق CSS برای پنهان کردن عناصر رابط کاربری نامربوط یا ارائه یک تجربه منسجم‌تر.
  • واسطه‌گری ارتباط امن: عمل کردن به عنوان یک دروازه‌بان با دریافت درخواست‌ها از صفحه جاسازی‌شده با postMessage و بازگرداندن فقط داده‌های ضروری و پاک‌سازی‌شده که از طریق APIهای دارای امتیاز دریافت می‌شوند.

مجاز نیست

  • سرقت اطلاعات کاربری: تزریق اسکریپت‌هایی برای دریافت رمزهای عبور، کوکی‌های جلسه یا سایر داده‌های حساس کاربر از محتوای جاسازی‌شده.
  • نقض شرایط خدمات: تغییر پلتفرم‌های تعبیه‌شده به روش‌هایی که شرایط خدمات آنها را نقض می‌کند، مانند کلیک کردن روی تبلیغات برنامه‌ریزی‌شده یا جمع‌آوری غیرمجاز اطلاعات.
  • پروکسی کردن دسترسی ممتاز: ایجاد یک گذرگاه که به محتوای جاسازی‌شده و غیرقابل اعتماد، دسترسی مستقیم یا کنترل‌نشده به یک API ممتاز IWA می‌دهد.
  • پیاده‌سازی هوش مصنوعی کنترل‌نشده: انجام اقدامات از طرف یک کاربر وارد شده از طریق هوش مصنوعی بدون محدودیت‌های خاص و شفاف در مورد استفاده.

ضبط صفحه نمایش بدون محدودیت

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

مجاز

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

مجاز نیست

  • ضبط مخفیانه: ضبط صفحه نمایش کاربر بدون اطلاع و رضایت صریح و آشکار او.
  • نقض مقررات حریم خصوصی: انجام هرگونه شیوه ضبط که قوانین حریم خصوصی محلی یا بین‌المللی را نقض کند.

وب‌یواس‌بی نامحدود

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

مجاز

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

اکنون مجاز است

  • دور زدن APIهای اختصاصی: استفاده از WebUSB برای دستگاه‌هایی که API خاص‌تر و محدودتری دارند، مانند کارت‌های هوشمند (استفاده از Smart Card API ) یا حافظه خارجی (استفاده از File System Access API ).

مدیریت پنجره ( window.open و window.focus )

IWAها می‌توانند بدون نیاز به ژست کاربر که در وب استاندارد الزامی است، پنجره‌های پاپ‌آپ و پنجره‌های فوکوس ایجاد کنند.

مجاز

  • اعلان اتمام وظیفه: متمرکز کردن پنجره برنامه هنگامی که یک وظیفه پس‌زمینه حیاتی که توسط کاربر آغاز شده است، مانند رندر ویدیو، به پایان رسید.

مجاز نیست

  • اسپم کردن: بمباران کاربر با پنجره‌های ناخواسته متعدد.
  • فیشینگ: باز کردن پنجره‌هایی که برای تقلید از دیالوگ‌های سیستم یا فریب کاربر طراحی شده‌اند.
  • سرقت تمرکز: ایجاد اختلال در کار کاربر با دزدیدن تمرکز از برنامه‌های دیگر برای رویدادهای غیرحیاتی.

نتیجه‌گیری

معماری امنیتی برنامه‌های وب ایزوله به گونه‌ای طراحی شده است که ضمن حفظ محیطی با اعتماد بالا برای کاربران، به توسعه‌دهندگان قدرت دهد. با رعایت این دستورالعمل‌ها، تضمین می‌کنید که برنامه شما همچنان یک شهروند مسئول در اکوسیستم IWA باقی بماند. مهم‌ترین نکات این راهنما عبارتند از:

  • اولویت دادن به شفافیت: رفتار برنامه شما باید همیشه با هدف تعیین‌شده‌اش همسو باشد؛ هرگز عملکردی را پیاده‌سازی نکنید که کاربر را غافلگیر کند یا به او خیانت کند.
  • اجرای یکپارچگی بسته: تمام منطق اجرایی باید در بسته IWA شما مستقل باشد تا امکان تأیید ایستا فراهم شود. دور زدن مدل امنیتی از طریق بارگذاری جانبی کد پویا یا مفسرهای از راه دور اکیداً ممنوع است.
  • پایبندی به حداقل امتیاز: همیشه محدودترین API موجود برای یک کار مشخص را انتخاب کنید. APIهای IWA با امتیاز بالا فقط باید زمانی استفاده شوند که APIهای وب استاندارد برای عملکرد اصلی برنامه کافی نباشند.
  • به عنوان یک دروازه‌بان عمل کنید: هنگام استفاده از ابزارهای قدرتمندی مانند <controlledframe> ، IWA شما باید به عنوان یک واسطه امن عمل کند، نه یک پروکسی شفاف برای محتوای غیرقابل اعتماد.

قبل از انتشار IWA خود، با پرسیدن سوالات زیر، یک ممیزی نهایی از پیاده‌سازی خود انجام دهید:

  1. آیا من از ساده‌ترین و محدودترین API ممکن برای این کار استفاده می‌کنم؟
  2. آیا کاربر از عملکرد برنامه من شگفت‌زده می‌شود یا احساس خیانت می‌کند؟

اگر پاسخ سوال اول «خیر» یا سوال دوم «بله» باشد، درخواست شما احتمالاً ناقض سیاست‌های امنیتی IWA است و ممکن است حذف شود.