تعریف "سایت یکسان" در حال تکامل است تا شامل طرح URL باشد، بنابراین پیوندهای بین نسخه های HTTP و HTTPS یک سایت اکنون به عنوان درخواست های بین سایتی به حساب می آیند. به‌طور پیش‌فرض به HTTPS ارتقا دهید تا در صورت امکان از مشکلات جلوگیری کنید یا برای جزئیات بیشتر مقادیر مشخصه SameSite مورد نیاز را بخوانید.
Schemeful Same-Site تعریف یک (وب) سایت را فقط از دامنه قابل ثبت به طرح + دامنه قابل ثبت تغییر می دهد. جزئیات و مثال‌های بیشتری را می‌توانید در درک "همان سایت" و "همان منبع" بیابید.
خبر خوب این است: اگر وب سایت شما در حال حاضر به طور کامل به HTTPS ارتقا یافته است، دیگر لازم نیست نگران چیزی باشید. هیچ چیز برای شما تغییر نخواهد کرد.
اگر هنوز وب سایت خود را به طور کامل ارتقا نداده اید، این باید در اولویت باشد. با این حال، اگر مواردی وجود دارد که بازدیدکنندگان سایت شما بین HTTP و HTTPS قرار می‌گیرند، برخی از آن سناریوهای رایج و رفتار کوکی SameSite مرتبط در زیر مشخص شده‌اند.
می توانید این تغییرات را برای آزمایش در کروم و فایرفاکس فعال کنید.
- از Chrome 86،
about://flags/#schemeful-same-siteرا فعال کنید. پیشرفت را در صفحه وضعیت Chrome پیگیری کنید. - از Firefox 79،
network.cookie.sameSite.schemefulرا رویtrueاز طریقabout:configتنظیم کنید. پیشرفت را از طریق مشکل Bugzilla پیگیری کنید.
یکی از دلایل اصلی تغییر به SameSite=Lax به عنوان پیش‌فرض کوکی‌ها، محافظت در برابر جعل درخواست متقابل (CSRF) بود. با این حال، ترافیک HTTP ناامن هنوز فرصتی را برای مهاجمان شبکه فراهم می کند تا کوکی هایی را دستکاری کنند که سپس در نسخه امن HTTPS سایت استفاده می شود. ایجاد این مرز بین سایتی اضافی بین طرح ها، دفاع بیشتر در برابر این حملات را فراهم می کند.
سناریوهای متقابل مشترک
جهت یابی
پیمایش بین نسخه‌های متقابل یک وب‌سایت (به عنوان مثال، پیوند از http ://site.example به https ://site.example) قبلاً امکان ارسال کوکی‌های SameSite=Strict را فراهم می‌کرد. این اکنون به عنوان یک پیمایش بین سایتی در نظر گرفته می شود که به این معنی است که SameSite=Strict مسدود خواهند شد.
| HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict | ⛔ مسدود شده | ⛔ مسدود شده |
SameSite=Lax | ✓ مجاز است | ✓ مجاز است |
SameSite=None;Secure | ✓ مجاز است | ⛔ مسدود شده |
بارگیری منابع فرعی
هر تغییری که در اینجا ایجاد می‌کنید فقط باید به عنوان یک اصلاح موقت در نظر گرفته شود، در حالی که برای ارتقا به HTTPS کامل کار می‌کنید.
نمونه‌هایی از منابع فرعی شامل تصاویر، آیفریم‌ها و درخواست‌های شبکه‌ای هستند که با XHR یا Fetch انجام شده‌اند.
بارگیری یک منبع فرعی متقاطع در یک صفحه قبلاً به کوکی‌های SameSite=Strict یا SameSite=Lax اجازه ارسال یا تنظیم می‌داد. اکنون با این مورد مانند سایر منابع فرعی شخص ثالث یا بین سایتی رفتار می شود که به این معنی است که هر کوکی SameSite=Strict یا SameSite=Lax مسدود خواهد شد.
به‌علاوه، حتی اگر مرورگر اجازه بارگیری منابع از طرح‌های ناامن را در یک صفحه امن بدهد، همه کوکی‌ها در این درخواست‌ها مسدود می‌شوند زیرا کوکی‌های شخص ثالث یا بین‌سایتی به Secure نیاز دارند.
| HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict | ⛔ مسدود شده | ⛔ مسدود شده |
SameSite=Lax | ⛔ مسدود شده | ⛔ مسدود شده |
SameSite=None;Secure | ✓ مجاز است | ⛔ مسدود شده |
ارسال فرم
ارسال بین نسخه های متقابل یک وب سایت قبلاً به کوکی های تنظیم شده با SameSite=Lax یا SameSite=Strict اجازه ارسال می دهد. اکنون این به عنوان یک POST بین سایتی تلقی می شود—تنها SameSite=None کوکی می تواند ارسال شود. ممکن است در سایت‌هایی که نسخه ناامن را به‌طور پیش‌فرض ارائه می‌کنند، با این سناریو مواجه شوید، اما با ارسال فرم ورود یا خروج، کاربران را به نسخه امن ارتقا دهید.
همانطور که در مورد منابع فرعی، اگر درخواست از یک زمینه امن، به عنوان مثال HTTPS، به یک زمینه ناامن، به عنوان مثال HTTP، تبدیل شود، همه کوکی ها در این درخواست ها مسدود می شوند زیرا کوکی های شخص ثالث یا بین سایتی نیاز به Secure دارند.
| HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict | ⛔ مسدود شده | ⛔ مسدود شده |
SameSite=Lax | ⛔ مسدود شده | ⛔ مسدود شده |
SameSite=None;Secure | ✓ مجاز است | ⛔ مسدود شده |
چگونه می توانم سایت خود را تست کنم؟
ابزارهای برنامه‌نویس و پیام‌رسانی در کروم و فایرفاکس در دسترس هستند.
از Chrome 86، برگه Issue در DevTools شامل مشکلات Schemeful Same-Site می شود. ممکن است مشکلات زیر را برای سایت خود برجسته کنید.
مشکلات ناوبری:
- "برای ادامه ارسال کوکی‌ها به درخواست‌های همان سایت، به طور کامل به HTTPS مهاجرت کنید" - هشداری مبنی بر مسدود شدن کوکی در نسخه بعدی Chrome.
- "به طور کامل به HTTPS مهاجرت کنید تا کوکی‌ها در درخواست‌های همان سایت ارسال شوند" - هشداری مبنی بر مسدود شدن کوکی.
مشکلات بارگیری منابع فرعی:
- «به طور کامل به HTTPS مهاجرت کنید تا کوکی‌ها به منابع فرعی همان سایت ارسال شوند» یا «به طور کامل به HTTPS مهاجرت کنید تا اجازه دهید کوکی‌ها توسط منابع فرعی همان سایت تنظیم شوند»—هشدارهایی مبنی بر مسدود شدن کوکی در نسخه بعدی Chrome.
- "به طور کامل به HTTPS مهاجرت کنید تا کوکی ها به منابع فرعی همان سایت ارسال شوند" یا "به طور کامل به HTTPS مهاجرت کنید تا کوکی ها توسط منابع فرعی همان سایت تنظیم شوند" - هشدارهایی مبنی بر مسدود شدن کوکی. هشدار دوم همچنین می تواند هنگام ارسال یک فرم ظاهر شود.
جزئیات بیشتر در نکات تست و رفع اشکال برای Schemeful Same-Site موجود است.
از فایرفاکس 79، با تنظیم network.cookie.sameSite.schemeful روی true از طریق about:config کنسول پیامی را برای مشکلات Schemeful Same-Site نمایش می دهد. ممکن است موارد زیر را در سایت خود مشاهده کنید:
- "Cookie
cookie_nameبه زودی به عنوان کوکی بین سایتی در برابرhttp://site.example/تلقی می شود زیرا این طرح مطابقت ندارد." - "Cookie
cookie_nameبه عنوان متقابل سایت در برابرhttp://site.example/در نظر گرفته شده است زیرا این طرح مطابقت ندارد."
سوالات متداول
سایت من در حال حاضر به طور کامل در HTTPS در دسترس است، چرا مشکلاتی را در DevTools مرورگر خود می بینم؟
ممکن است برخی از پیوندها و منابع فرعی شما همچنان به URL های ناامن اشاره کنند.
یکی از راه‌های رفع این مشکل استفاده از HTTP Strict-Transport-Security (HSTS) و دستورالعمل includeSubDomain است. با HSTS + includeSubDomain حتی اگر یکی از صفحات شما به طور تصادفی یک پیوند ناامن داشته باشد، مرورگر به طور خودکار از نسخه امن استفاده می کند.
اگر نتوانم به HTTPS ارتقا دهم چه می شود؟
در حالی که ما قویاً توصیه می کنیم برای محافظت از کاربران خود، سایت خود را به طور کامل به HTTPS ارتقا دهید، اگر خودتان نمی توانید این کار را انجام دهید، پیشنهاد می کنیم با ارائه دهنده هاست خود صحبت کنید تا ببینید آیا آنها می توانند این گزینه را ارائه دهند یا خیر. اگر خود میزبان هستید، Let's Encrypt تعدادی ابزار برای نصب و پیکربندی یک گواهی ارائه می دهد. همچنین می توانید بررسی کنید که سایت خود را پشت یک CDN یا پروکسی دیگری که می تواند اتصال HTTPS را فراهم کند، جابجا شود.
اگر هنوز امکان پذیر نیست، سعی کنید حفاظت SameSite را در کوکی های آسیب دیده کاهش دهید.
- در مواردی که فقط کوکی‌های
SameSite=Strictمسدود شده‌اند، می‌توانید حفاظت را بهLaxکاهش دهید. - در مواردی که کوکی‌های
StrictوLaxمسدود می‌شوند و کوکی‌های شما به یک URL امن ارسال می‌شوند (یا از آن تنظیم می‌شوند)، می‌توانید حفاظت‌ها را بهNoneکاهش دهید.- اگر URL که کوکی‌ها را به آن ارسال می‌کنید (یا از آن تنظیم می‌کنید) ناامن باشد، این راه‌حل با شکست مواجه می‌شود. این به این دلیل است که
SameSite=Noneبه ویژگیSecureروی کوکی ها نیاز دارد که به این معنی است که این کوکی ها ممکن است از طریق یک اتصال ناامن ارسال یا تنظیم نشوند. در این صورت تا زمانی که سایت شما به HTTPS ارتقا پیدا نکند، نمی توانید به آن کوکی دسترسی پیدا کنید. - به یاد داشته باشید، این فقط موقتی است زیرا در نهایت کوکی های شخص ثالث به طور کامل حذف خواهند شد.
- اگر URL که کوکی‌ها را به آن ارسال می‌کنید (یا از آن تنظیم می‌کنید) ناامن باشد، این راه‌حل با شکست مواجه می‌شود. این به این دلیل است که
اگر ویژگی SameSite را مشخص نکرده باشم، این چگونه روی کوکی‌های من تأثیر می‌گذارد؟
با کوکی‌های بدون ویژگی SameSite به‌گونه‌ای رفتار می‌شود که گویی SameSite=Lax مشخص کرده‌اند و همین رفتار متقابل برای این کوکی‌ها نیز اعمال می‌شود. توجه داشته باشید که استثنای موقت برای روش‌های ناامن همچنان اعمال می‌شود، برای اطلاعات بیشتر به کاهش Lax + POST در سؤالات متداول Chromium SameSite مراجعه کنید.
WebSocket ها چگونه تحت تأثیر قرار می گیرند؟
اتصالات WebSocket همچنان همان سایت در نظر گرفته می شوند، اگر از امنیت یکسانی با صفحه برخوردار باشند.
همان سایت:
- اتصال
wss://ازhttps:// - اتصال
ws://ازhttp://
متقابل سایت:
- اتصال
wss://ازhttp:// - اتصال
ws://ازhttps://
عکس توسط Julissa Capdevilla در Unsplash