به روز رسانی دسترسی به شبکه خصوصی: معرفی آزمایشی منسوخ شدن

تیتون ریگودی
Titouan Rigoudy
یفان لو
Yifan Luo
GitHub

به روز رسانی ها

  • 23 مارس 2023 : جدول زمانی به‌روزرسانی شده است و تا Chrome 117 منسوخ نخواهد شد.

  • 19 ژانویه 2023 : جدول زمانی به‌روزرسانی شده است و تا Chrome 114 منسوخ نخواهد شد.

  • 12 آگوست 2022 : جدول زمانی به‌روزرسانی شده است و تا Chrome 109 منسوخ نخواهد شد.

  • 10 فوریه 2022 : مقاله به روز شده در دسترسی به شبکه خصوصی منتشر شد: معرفی پروازهای پیش از پرواز

  • 25 اوت 2021 : اعلام جدول زمانی به روز شده و معرفی آزمایشی منسوخ شدن.

Chrome دسترسی به نقاط پایانی شبکه خصوصی از وب‌سایت‌های غیر ایمن را به عنوان بخشی از مشخصات دسترسی به شبکه خصوصی منسوخ می‌کند. هدف محافظت از کاربران در برابر حملات جعل درخواست متقابل (CSRF) است که روترها و سایر دستگاه‌ها را در شبکه‌های خصوصی هدف قرار می‌دهند. این حملات صدها هزار کاربر را تحت تأثیر قرار داده است و به مهاجمان اجازه می دهد آنها را به سرورهای مخرب هدایت کنند.

کروم تغییرات زیر را معرفی خواهد کرد:

  • مسدود کردن درخواست‌ها به شبکه‌های خصوصی از وب‌سایت‌های عمومی ناامن از Chrome 94.
  • معرفی یک دوره آزمایشی منسوخ شدن که در Chrome به پایان می رسد
    1. این به توسعه دهندگان اجازه می دهد تا برای مبداهای انتخابی تمدید زمانی درخواست کنند، که در طول دوره آزمایشی منسوخ شدن تأثیری نخواهد داشت.
  • معرفی یک خط‌مشی Chrome که به استقرارهای مدیریت‌شده Chrome اجازه می‌دهد تا به‌طور دائم از منسوخ شدن دور بزنند. موجود در کروم 92.

اگر به زمان بیشتری برای کاهش تأثیر ثبت استهلاک برای آزمایش استهلاک نیاز دارید.

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

برای کاهش تأثیر محدودیت‌های جدید، از یکی از استراتژی‌های زیر استفاده کنید:

جدول زمانی

  • نوامبر 2020: برای بازخورد در مورد تغییرات آتی تماس بگیرید .
  • مارس 2021: پس از بررسی بازخورد و اطلاع رسانی، تغییرات آتی اعلام می شود. مشخصات از CORS-RFC1918 به دسترسی به شبکه خصوصی تغییر نام داده است.
  • آوریل 2021: Chrome 90 به Stable عرضه شد و هشدارهای منسوخ شدن ظاهر شد.
  • ژوئن 2021: Chrome 92 به نسخه بتا عرضه شد و درخواست‌های شبکه خصوصی از زمینه‌های ناامن را ممنوع کرد. پس از بازخورد برنامه‌نویسان که زمان بیشتری برای تنظیم درخواست می‌کنند، منسوخ شدن به Chrome 93 موکول می‌شود تا با یک آزمایش منسوخ شدن همراه شود.
  • جولای 2021: پس از بازخورد بیشتر از سوی توسعه‌دهندگان، منسوخ شدن و دوره آزمایشی همراه آن به Chrome 94 موکول شد. علاوه بر این، وب‌سایت‌های خصوصی دیگر تحت تأثیر این لغو قرار نمی‌گیرند.
  • آگوست 2021: Chrome 94 به نسخه بتا عرضه شد. توسعه دهندگان وب می توانند شروع به ثبت نام برای آزمایشی منسوخ شدن کنند.
  • سپتامبر 2021: Chrome 94 به Stable عرضه شد. توسعه دهندگان وب باید برای آزمایش منسوخ شدن ثبت نام می کردند و توکن های آزمایشی را برای تولید مستقر می کردند.
  • دسامبر 2022: بررسی آزمایشی مبدا ارسال شد و بازخورد دریافت شد. دوره آزمایشی منسوخ شدن به Chrome 113 تمدید شد.
  • مارس 2023: دوره آزمایشی منسوخ شدن به Chrome 116 تمدید شد و قرار است در Chrome 117 به پایان برسد . مکانیزم جایگزین مبتنی بر مجوز در حال توسعه است که انتشار اولیه در Chrome 114 را هدف قرار می‌دهد.
  • مه 2023 (آزمایشی): مکانیسم مبتنی بر مجوز در Chrome 114 ارائه می‌شود. وب‌سایت‌ها می‌توانند از آن برای خروج از دوره آزمایشی منسوخ شدن استفاده کنند.
  • سپتامبر 2023: Chrome 117 به Stable عرضه شد و به دوره آزمایشی منسوخ پایان داد. Chrome همه درخواست‌های شبکه خصوصی را از زمینه‌های عمومی و غیرایمن مسدود می‌کند.

دسترسی به شبکه خصوصی چیست؟

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

درخواست‌های شبکه خصوصی درخواست‌هایی هستند که آدرس IP سرور مورد نظر آنها خصوصی‌تر از آن چیزی است که آغازگر درخواست از آن واکشی شده است. به عنوان مثال، یک درخواست از یک وب سایت عمومی ( https://example.com ) به یک وب سایت خصوصی ( http://router.local )، یا یک درخواست از یک وب سایت خصوصی به لوکال هاست.

ارتباط بین شبکه های عمومی، خصوصی و محلی در دسترسی به شبکه خصوصی (CORS-RFC1918).
ارتباط بین شبکه های عمومی، خصوصی و محلی در دسترسی به شبکه خصوصی (CORS-RFC1918).

در بازخورد مورد نظر بیشتر بیاموزید: CORS برای شبکه های خصوصی (RFC1918) .

محاکمه استهلاک چیست

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

در طول دوره آزمایشی منسوخ، ویژگی های منسوخ شده به طور پیش فرض برای همه وب سایت ها در دسترس نیستند. توسعه‌دهندگانی که هنوز نیاز به استفاده از ویژگی‌های آسیب‌دیده دارند، باید برای آزمایش منسوخ شدن ثبت‌نام کنند و توکن‌هایی را برای مبداهای مشخص شده وب دریافت کنند، سپس وب‌سایت‌های خود را تغییر دهند تا آن نشانه‌ها را در هدرهای HTTP یا متا تگ‌ها (به جز در این مورد) ارائه دهند. اگر وب‌سایتی توکن‌های معتبری را ارائه می‌دهد که منشا آن‌ها مطابقت دارند، Chrome اجازه استفاده از ویژگی منسوخ شده را برای مدت زمان محدودی می‌دهد.

برای اطلاعات بیشتر، شروع به کار با آزمایش‌های اولیه Chrome و راهنمای توسعه‌دهنده وب برای آزمایش‌های اصلی را برای دستورالعمل‌ها بررسی کنید.

آنچه در کروم در حال تغییر است

کروم 94

از Chrome 94، زمینه‌های عمومی غیرایمن (به طور کلی، وب‌سایت‌هایی که از طریق HTTPS یا از یک آدرس IP خصوصی ارائه نمی‌شوند) از درخواست به شبکه خصوصی منع شده‌اند. این قبلاً برای Chrome 92 برنامه‌ریزی شده بود، بنابراین پیام‌های لغو ممکن است همچنان نقطه عطف قبلی را ذکر کنند.

این منسوخ شدن با یک آزمایش منسوخ همراه است که به توسعه دهندگان وب که وب سایت آنها از این ویژگی منسوخ شده استفاده می کنند اجازه می دهد تا با ثبت نام برای توکن ها، به استفاده از آن تا Chrome 116 ادامه دهند. برای دستورالعمل های نحوه ثبت نام و فعال کردن آزمایشی در وب سایت خود به زیر مراجعه کنید.

از یک جفت خط‌مشی Chrome می‌توان برای غیرفعال کردن کامل یا در مبداهای خاص به طور نامحدود استفاده کرد. این به نصب‌های مدیریت‌شده Chrome، برای مثال، آن‌هایی که در تنظیمات شرکتی هستند، اجازه می‌دهد تا از شکستگی جلوگیری کنند.

کروم 117

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

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

برای آزمایش انحلال ثبت نام کنید

  1. برای دریافت نسخه آزمایشی برای منبع شرکت کننده، روی ثبت نام برای دسترسی به شبکه خصوصی از زمینه آزمایشی مبدا غیرایمن کلیک کنید.
  2. Origin-Trial: $token به سرصفحه پاسخ خود اضافه کنید. این سرصفحه پاسخ فقط باید روی پاسخ های منبع اصلی و ناوبری تنظیم شود که سند حاصل از ویژگی منسوخ استفاده کند. پیوستن این هدر به پاسخ‌های منبع فرعی بی فایده (هرچند بی ضرر) است.

از آنجایی که این آزمایش باید قبل از اینکه سند اجازه درخواست درخواست دهد، فعال یا غیرفعال شود، نمی توان آن را از طریق تگ <meta> فعال کرد. چنین تگ‌هایی تنها پس از صدور درخواست‌های منبع فرعی از بدنه پاسخ تجزیه می‌شوند. این یک چالش برای وب‌سایت‌هایی است که کنترل سرصفحه‌های پاسخ را ندارند، مانند وب‌سایت‌های static github.io که توسط شخص ثالث ارائه می‌شوند.

برای جزئیات بیشتر، راهنمای توسعه‌دهنده وب برای آزمایش‌های اولیه را ببینید.

فعال کردن خط مشی ها

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

برای جزئیات بیشتر درباره مدیریت خط‌مشی‌ها برای کاربرانتان، به این مقاله مرکز راهنمایی مراجعه کنید.

دسترسی به لوکال هاست

اگر وب سایت شما نیاز به درخواست برای لوکال هاست دارد، فقط باید وب سایت خود را به HTTPS ارتقا دهید .

درخواست‌هایی که http://localhost (یا http://127.*.*.* ، http://[::1] ) را هدف قرار می‌دهند، توسط محتوای مختلط مسدود نمی‌شوند، حتی زمانی که از زمینه‌های امن صادر شده باشند.

توجه داشته باشید که موتور WebKit و مرورگرهای مبتنی بر آن (به ویژه سافاری) از مشخصات محتوای ترکیبی W3C در اینجا منحرف شده و این درخواست‌ها را به عنوان محتوای ترکیبی ممنوع می‌کند . آن‌ها همچنین دسترسی به شبکه خصوصی را پیاده‌سازی نمی‌کنند، بنابراین وب‌سایت‌ها ممکن است بخواهند مشتریانی را که از چنین مرورگرهایی استفاده می‌کنند، به یک نسخه HTTP متن ساده وب‌سایت هدایت کنند، که همچنان توسط چنین مرورگرهایی مجاز به درخواست به لوکال هاست است.

دسترسی به آدرس های IP خصوصی

اگر وب سایت شما نیاز به ارسال درخواست به یک سرور هدف در یک آدرس IP خصوصی دارد، به سادگی ارتقاء وب سایت آغازگر به HTTPS کار نمی کند. محتوای مختلط از ایجاد درخواست از طریق HTTP متن ساده توسط زمینه‌های امن جلوگیری می‌کند، بنابراین وب‌سایت تازه ایمن‌شده همچنان نمی‌تواند درخواست‌ها را ارسال کند. چند راه برای حل این مشکل وجود دارد:

  • هر دو طرف را به HTTPS ارتقا دهید.
  • از WebTransport برای اتصال ایمن به سرور مورد نظر استفاده کنید.
  • رابطه جاسازی را معکوس کنید.

هر دو طرف را به HTTPS ارتقا دهید

این راه حل نیاز به کنترل روی وضوح DNS کاربران دارد، مانند مواردی که ممکن است در زمینه های اینترانت رخ دهد، یا اگر کاربران آدرس سرورهای نام خود را از یک سرور DHCP تحت کنترل شما دریافت کنند. همچنین مستلزم داشتن یک نام دامنه عمومی است.

مشکل اصلی ارائه وب‌سایت‌های خصوصی از طریق HTTPS این است که مقامات گواهی زیرساخت کلید عمومی (PKI CA) فقط گواهی‌های TLS را به وب‌سایت‌هایی با نام دامنه عمومی ارائه می‌کنند. برای کار در این مورد:

  1. یک نام دامنه عمومی (به عنوان مثال intranet.example ) ثبت کنید و سوابق DNS را منتشر کنید که نام دامنه را به سرور عمومی انتخابی شما نشان می دهد.
  2. یک گواهی TLS برای intranet.example دریافت کنید.
  3. در داخل شبکه خصوصی خود، DNS را پیکربندی کنید تا intranet.example را در آدرس IP خصوصی سرور مورد نظر حل کند.
  4. سرور خصوصی خود را برای استفاده از گواهی TLS برای intranet.example پیکربندی کنید. این به کاربران شما اجازه می دهد تا به سرور خصوصی در https://intranet.example دسترسی داشته باشند.

سپس می‌توانید وب‌سایتی را که درخواست‌ها را آغاز می‌کند به HTTPS ارتقا دهید و درخواست‌ها را مانند قبل ادامه دهید.

این راه حل آینده نگر است و اعتماد شما به شبکه خود را کاهش می دهد و استفاده از رمزگذاری انتها به انتها را در شبکه خصوصی شما گسترش می دهد.

وب حمل و نقل

این راه حل نیازی به کنترل رزولوشن DNS کاربران شما ندارد. این نیاز دارد که سرور مورد نظر یک سرور WebTransport (سرور HTTP/3 با برخی تغییرات) را اجرا کند.

با استفاده از WebTransport و مکانیزم پین کردن گواهی آن، می‌توانید عدم وجود گواهی TLS معتبر امضا شده توسط یک CA مورد اعتماد را دور بزنید. این اجازه می دهد تا اتصالات ایمن را با دستگاه های خصوصی که ممکن است به عنوان مثال دارای گواهی امضا شده باشند، برقرار کنید. اتصالات WebTransport انتقال داده دو طرفه را امکان پذیر می کند، اما درخواست واکشی نمی کند. می‌توانید این رویکرد را با یک سرویس‌کار ترکیب کنید تا به‌طور شفاف درخواست‌های HTTP را از نقطه‌نظر برنامه‌ی وب خود، از طریق اتصال، پراکسی کنید. در سمت سرور، یک لایه ترجمه مربوطه می تواند پیام های WebTransport را به درخواست های HTTP تبدیل کند.

ما تصدیق می کنیم که این نشان دهنده مقدار عادلانه کار است، اما باید به طور قابل توجهی ساده تر از ساختن بر روی WebRTC باشد. همچنین امید ما این است که مقداری از سرمایه گذاری لازم به عنوان کتابخانه های قابل استفاده مجدد اجرا شود. ما همچنین معتقدیم که با توجه به این واقعیت که زمینه‌های غیرایمن به احتمال زیاد دسترسی به ویژگی‌های بیشتر و بیشتر پلتفرم وب را از دست می‌دهند، زیرا پلتفرم به سمت تشویق استفاده از HTTPS به روش‌های قوی‌تر در طول زمان حرکت می‌کند، معتقدیم. صرف نظر از دسترسی به شبکه خصوصی، به هر حال این احتمالا سرمایه گذاری عاقلانه ای خواهد بود.

ما انتظار داریم WebTransport از طریق HTTP/3 در Chrome 96 ( آزمایی اولیه آن آغاز شده است) با اقدامات کاهشی برای محافظت در برابر اشتراک گذاری کلید و سایر اقدامات امنیتی غیر استاندارد، از جمله:

  • حداکثر زمان انقضا کوتاه برای گواهی های پین شده.
  • مکانیزم مخصوص مرورگر برای لغو کلیدهای خاصی که مورد سوء استفاده قرار گرفته اند.

ما محدودیت زمینه ایمن را تا حداقل دو نقطه عطف پس از راه اندازی کامل WebTransport ارسال نمی کنیم. در صورت نیاز، دوره آزمایشی انحلال تمدید خواهد شد.

تعبیه معکوس

این راه حل نیازی به هیچ گونه کنترل مدیریتی بر روی شبکه ندارد و زمانی می توان از آن استفاده کرد که سرور هدف به اندازه کافی برای اجرای HTTPS قدرتمند نباشد.

به جای واکشی زیرمنابع خصوصی از یک برنامه وب عمومی، یک اسکلت برنامه را می توان از سرور خصوصی ارائه کرد، که سپس تمام منابع فرعی آن (مانند اسکریپت ها یا تصاویر) را از یک سرور عمومی، مانند CDN، واکشی می کند. سپس برنامه وب حاصل می‌تواند درخواست‌هایی را به سرور خصوصی ارسال کند، زیرا اینها منشا یکسانی در نظر گرفته می‌شوند. حتی می‌تواند به سرورهای دیگر با IP خصوصی (اما نه لوکال هاست) درخواست کند، اگرچه ممکن است در دراز مدت این مورد تغییر کند.

با میزبانی فقط یک اسکلت در سرور خصوصی، می توانید برنامه وب را با فشار دادن منابع جدید به سرور عمومی به روز کنید، درست همانطور که یک برنامه وب عمومی را به روز می کنید. از سوی دیگر، برنامه وب ایجاد شده یک زمینه امن نیست، بنابراین به برخی از ویژگی های قدرتمندتر وب دسترسی ندارد.

برنامه ها برای آینده

محدود کردن درخواست‌های شبکه خصوصی به زمینه‌های امن تنها اولین قدم در راه‌اندازی دسترسی به شبکه خصوصی است. کروم برای پیاده سازی بقیه مشخصات در ماه های آینده کار می کند. منتظر به روز رسانی ها باشید!

محدود کردن دسترسی لوکال هاست از وب سایت های خصوصی

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

درخواست های CORS قبل از پرواز

بخش دوم دسترسی به شبکه خصوصی این است که درخواست‌های شبکه خصوصی را که از زمینه‌های امن با درخواست‌های پیش از پرواز CORS آغاز می‌شوند، درب‌گذاری کنید. ایده این است که حتی زمانی که درخواست از یک زمینه امن آغاز شده است، از سرور مورد نظر خواسته می شود تا یک کمک مالی صریح به آغازگر ارائه دهد. درخواست تنها در صورت موفقیت آمیز بودن کمک هزینه ارسال می شود.

به طور خلاصه، یک درخواست پیش از پرواز CORS یک درخواست HTTP OPTIONS است که دارای سرصفحه های Access-Control-Request-* است که ماهیت درخواست بعدی را نشان می دهد. سپس سرور می‌تواند با پاسخ دادن 200 OK با هدرهای Access-Control-Allow-* تصمیم بگیرد که آیا دسترسی دقیق را اعطا کند یا خیر.

جزئیات بیشتر در مورد این را در مشخصات بیابید.

واکشی پیمایش را محدود کنید

کروم در حال منسوخ شدن و در نهایت مسدود کردن درخواست‌های منابع فرعی برای شبکه‌های خصوصی است. این روی ناوبری به شبکه های خصوصی تأثیر نمی گذارد، که می تواند در حملات CSRF نیز استفاده شود.

مشخصات دسترسی به شبکه خصوصی تمایزی بین این دو نوع واکشی قائل نمی‌شود، که در نهایت مشمول محدودیت‌های یکسانی خواهند بود.

عکس روی جلد توسط Markus Spiske در Unsplash