خطرات مرتبط با قرار گرفتن ناخواسته دستگاه ها و سرورها در شبکه داخلی مشتری در سطح وب را کاهش دهید.
وبسایتهای مخربی که از دستگاهها و سرورهای میزبانی شده در یک شبکه خصوصی درخواست میکنند، مدتهاست که یک تهدید محسوب میشوند. برای مثال، مهاجمان ممکن است پیکربندی روتر بی سیم را برای فعال کردن حملات Man-in-the-Middle تغییر دهند. CORS-RFC1918 پیشنهادی برای مسدود کردن چنین درخواستهایی بهطور پیشفرض در مرورگر است و به دستگاههای داخلی نیاز دارد تا درخواستهای اینترنت عمومی را انتخاب کنند.
برای درک اینکه این تغییر چگونه بر اکوسیستم وب تأثیر میگذارد، تیم Chrome به دنبال بازخورد توسعهدهندگانی است که برای شبکههای خصوصی سرور میسازند.
چه اشکالی در وضعیت موجود وجود دارد؟
بسیاری از وب سرورها در یک شبکه خصوصی اجرا می شوند - روترهای بی سیم، چاپگرها، وب سایت های اینترانت، خدمات سازمانی و دستگاه های اینترنت اشیا (IoT) تنها بخشی از آنها هستند. ممکن است به نظر برسد که آنها در محیط امنتری نسبت به محیطهایی هستند که در معرض عموم قرار میگیرند، اما این سرورها میتوانند توسط مهاجمانی که از یک صفحه وب به عنوان پروکسی استفاده میکنند مورد سوء استفاده قرار گیرند. برای مثال، وبسایتهای مخرب میتوانند URLی را جاسازی کنند که وقتی قربانی به سادگی آن را مشاهده میکند (در مرورگر دارای جاوا اسکریپت)، سعی میکند تنظیمات سرور DNS را در روتر پهنباند خانگی قربانی تغییر دهد. این نوع حمله " Drive-By Pharming " نام دارد و در سال 2014 اتفاق افتاد . بیش از 300000 روتر بی سیم آسیب پذیر با تغییر تنظیمات DNS و اجازه دادن به مهاجمان برای هدایت کاربران به سرورهای مخرب مورد سوء استفاده قرار گرفتند.
CORS-RFC1918
برای کاهش خطر حملات مشابه، جامعه وب در حال ارائه CORS-RFC1918 — اشتراک منبع متقاطع (CORS) تخصصی برای شبکه های خصوصی تعریف شده در RFC1918 است.
مرورگرهایی که CORS را پیادهسازی میکنند، با منابع هدف بررسی میکنند که آیا آنها از منبع دیگری بارگیری میشوند یا خیر. این کار یا با سرصفحههای اضافی درون خطی که دسترسی را توصیف میکنند یا با استفاده از مکانیزمی به نام درخواستهای پیش از پرواز، بسته به پیچیدگی، انجام میشود. برای کسب اطلاعات بیشتر ، Cross Origin Resource Sharing را بخوانید.
با CORS-RFC1918، مرورگر بهطور پیشفرض، بارگیری منابع را روی شبکه خصوصی مسدود میکند، به جز مواردی که صراحتاً توسط سرور با استفاده از CORS و از طریق HTTPS مجاز است. وبسایتی که از آن منابع درخواست میکند باید سرصفحههای CORS را ارسال کند و سرور باید صریحاً اعلام کند که با پاسخ دادن به سرفصلهای CORS مربوطه، درخواست متقاطع را میپذیرد. ( هدرهای دقیق CORS هنوز در دست توسعه هستند.)
از توسعه دهندگان چنین دستگاه ها یا سرورهایی خواسته می شود که دو کار را انجام دهند:
- اطمینان حاصل کنید که وبسایتی که درخواستهایی به یک شبکه خصوصی میدهد از طریق HTTPS ارائه میشود.
- پشتیبانی سرور را برای CORS-RFC1918 تنظیم کنید و با هدرهای HTTP مورد انتظار پاسخ دهید.
چه نوع درخواست هایی تحت تأثیر قرار می گیرند؟
درخواست های تحت تأثیر عبارتند از:
- درخواست از شبکه عمومی به یک شبکه خصوصی
- درخواست از یک شبکه خصوصی به یک شبکه محلی
- درخواست از شبکه عمومی به یک شبکه محلی
یک شبکه خصوصی مقصدی که به فضای آدرس خصوصی تعریف شده در بخش 3 RFC1918 در IPv4، یک آدرس IPv6 نقشهبرداری شده با IPv4 که در آن آدرس IPv4 نگاشت شده خود خصوصی است، یا یک آدرس IPv6 خارج از ::1/128
، 2000::/3
زیر شبکه های 2000::/3
و ff00::/8
.
یک شبکه محلی مقصدی که به فضای "Loopback" ( 127.0.0.0/8
) تعریف شده در بخش 3.2.1.3 از RFC1122 IPv4، فضای "لینک محلی" ( 169.254.0.0/16
) تعریف شده در RFC3927 IPv4 تعیین می شود. ، پیشوند "آدرس محلی منحصر به فرد" ( fc00::/7
) تعریف شده در بخش 3 از RFC4193 IPv6، یا پیشوند "پیوند-محلی" ( fe80::/10
) تعریف شده در بخش 2.5.6 از RFC4291 IPv6.
یک شبکه عمومی همه بقیه.
برنامه کروم برای فعال کردن CORS-RFC1918
کروم CORS-RFC1918 را در دو مرحله ارائه میکند:
مرحله 1: درخواست به منابع شبکه خصوصی فقط از صفحات وب HTTPS مجاز خواهد بود
Chrome 87 پرچمی را اضافه میکند که وبسایتهای عمومی را که به منابع شبکه خصوصی درخواست میکنند را موظف میکند تا در HTTPS باشند. برای فعال کردن آن می توانید به about://flags#block-insecure-private-network-requests
بروید. با روشن بودن این پرچم، هرگونه درخواست به یک منبع شبکه خصوصی از یک وب سایت HTTP مسدود می شود.
از Chrome 88، خطاهای CORS-RFC1918 به عنوان خطاهای خطمشی CORS در کنسول گزارش میشود.
در پانل شبکه Chrome DevTools میتوانید کادر بررسی درخواستهای مسدود شده را فعال کنید تا روی درخواستهای مسدود شده تمرکز کنید:
در Chrome 87، خطاهای CORS-RFC1918 فقط در DevTools Console بهعنوان ERR_INSECURE_PRIVATE_NETWORK_REQUEST
گزارش میشوند.
می توانید خودتان با استفاده از این وب سایت تست آن را امتحان کنید.
مرحله 2: ارسال درخواست های قبل از پرواز با هدر ویژه
در آینده، هر زمان که یک وبسایت عمومی بخواهد منابعی را از یک شبکه خصوصی یا محلی واکشی کند، Chrome قبل از درخواست واقعی یک درخواست پیش از پرواز ارسال میکند.
این درخواست شامل یک Access-Control-Request-Private-Network: true
علاوه بر سایر سرصفحه های درخواست CORS خواهد بود. از جمله موارد دیگر، این هدرها مبدا درخواست را شناسایی می کنند و امکان کنترل دسترسی دقیق را فراهم می کنند. سرور می تواند با یک هدر Access-Control-Allow-Private-Network: true
پاسخ دهد تا به صراحت نشان دهد که به منبع دسترسی می دهد.
بازخورد خواسته شد
اگر وبسایتی را در یک شبکه خصوصی میزبانی میکنید که انتظار درخواستهایی از شبکههای عمومی را دارد، تیم Chrome به بازخورد و موارد استفاده شما علاقهمند است. دو کار وجود دارد که می توانید برای کمک انجام دهید:
- به
about://flags#block-insecure-private-network-requests
بروید، پرچم را روشن کنید و ببینید آیا وب سایت شما درخواست ها را همانطور که انتظار می رود به منبع شبکه خصوصی ارسال می کند یا خیر. - اگر با مشکلی مواجه شدید یا بازخورد دارید، مشکلی را در crbug.com ثبت کنید و مؤلفه را روی
Blink>SecurityFeature>CORS>RFC1918
تنظیم کنید.
بازخورد نمونه
روتر بی سیم ما یک وب سایت مدیریت را برای همان شبکه خصوصی اما از طریق HTTP ارائه می دهد. اگر HTTPS برای وبسایتهایی که وبسایت مدیریت را تعبیه میکنند مورد نیاز باشد، محتوای ترکیبی خواهد بود. آیا باید HTTPS را در وب سایت مدیریت در یک شبکه بسته فعال کنیم؟
این دقیقا همان نوع بازخوردی است که کروم به دنبال آن است. لطفاً یک مشکل در مورد استفاده بتن خود در crbug.com ثبت کنید. Chrome دوست دارد از شما بشنود.
تصویر قهرمان توسط استیون فیلیپس در Unsplash .