تعریف "سایت یکسان" در حال تکامل است تا شامل طرح 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