تعریف «same-site» در حال تکامل است تا طرح URL را نیز شامل شود، بنابراین لینکهای بین نسخههای HTTP و HTTPS یک سایت اکنون به عنوان درخواستهای بین سایتی محسوب میشوند. برای جلوگیری از مشکلات، در صورت امکان، به طور پیشفرض به HTTPS ارتقا دهید یا برای جزئیات بیشتر در مورد مقادیر مورد نیاز برای ویژگیهای SameSite، ادامه مطلب را بخوانید.
Schemeful Same-Site تعریف یک (وبسایت) را از فقط دامنه قابل ثبت به طرح + دامنه قابل ثبت تغییر میدهد. میتوانید جزئیات و مثالهای بیشتری را در درک «same-site» و «same-origin» بیابید.
خبر خوب این است: اگر وبسایت شما از قبل به طور کامل به HTTPS ارتقا یافته است، دیگر لازم نیست نگران چیزی باشید. هیچ چیز برای شما تغییر نخواهد کرد.
اگر هنوز وبسایت خود را به طور کامل ارتقا ندادهاید، این باید در اولویت باشد. با این حال، اگر مواردی وجود دارد که بازدیدکنندگان سایت شما بین HTTP و HTTPS جابجا میشوند، برخی از این سناریوهای رایج و رفتار کوکی SameSite مرتبط با آن، بعداً در این مقاله شرح داده شده است.
میتوانید این تغییرات را برای آزمایش در هر دو مرورگر کروم و فایرفاکس فعال کنید.
- از کروم ۸۶،
about://flags/#schemeful-same-siteفعال کنید. پیشرفت را در صفحه وضعیت کروم پیگیری کنید. - از فایرفاکس ۷۹،
network.cookie.sameSite.schemefulرا از طریقabout:configرویtrueتنظیم کنید. با استفاده از مشکل 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 کامل تلاش کنید.
نمونههایی از زیرمنابع شامل تصاویر، iframeها و درخواستهای شبکهای هستند که با XHR یا Fetch انجام میشوند.
بارگذاری یک زیرمنبع cross-scheme در یک صفحه، پیش از این به کوکیهای SameSite=Strict یا SameSite=Lax اجازه ارسال یا تنظیم میداد. اکنون با این مورد مانند هر زیرمنبع شخص ثالث یا بینسایتی دیگری رفتار میشود، به این معنی که هرگونه کوکی SameSite=Strict یا SameSite=Lax مسدود خواهد شد.
علاوه بر این، حتی اگر مرورگر اجازه دهد منابع از طرحهای ناامن در یک صفحه امن بارگذاری شوند، تمام کوکیها در این درخواستها مسدود میشوند زیرا کوکیهای شخص ثالث یا بین سایتی Secure نیاز دارند.
| HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict | ⛔ مسدود شده | ⛔ مسدود شده |
SameSite=Lax | ⛔ مسدود شده | ⛔ مسدود شده |
SameSite=None;Secure | ✓ مجاز | ⛔ مسدود شده |
ارسال فرم
ارسال پست بین نسخههای cross-scheme یک وبسایت قبلاً اجازه ارسال کوکیهایی که با SameSite=Lax یا SameSite=Strict تنظیم شده بودند را میداد. اکنون این به عنوان یک POST بین-سایتی در نظر گرفته میشود - فقط SameSite=None کوکیها میتوانند ارسال شوند. ممکن است در سایتهایی که به طور پیشفرض نسخه ناامن را ارائه میدهند، با این سناریو مواجه شوید، اما کاربران را هنگام ارسال فرم ورود یا خروج به نسخه امن ارتقا دهید.
همانند زیرمنابع، اگر درخواست از یک بستر امن (مثلاً HTTPS) به یک بستر ناامن (مثلاً HTTP) باشد، تمام کوکیها در این درخواستها مسدود میشوند زیرا کوکیهای شخص ثالث یا بینسایتی Secure نیاز دارند.
| HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict | ⛔ مسدود شده | ⛔ مسدود شده |
SameSite=Lax | ⛔ مسدود شده | ⛔ مسدود شده |
SameSite=None;Secure | ✓ مجاز | ⛔ مسدود شده |
چطور میتوانم سایتم را تست کنم؟
ابزارهای توسعهدهندگان و پیامرسانی در کروم و فایرفاکس در دسترس هستند.
از کروم ۸۶، تب «مسائل» در DevTools شامل مشکلات Schemeful Same-Site خواهد بود. ممکن است مشکلات زیر را برای سایت خود برجسته کنید.
مشکلات ناوبری:
- «برای ادامه ارسال کوکیها در درخواستهای همان سایت، بهطور کامل به HTTPS مهاجرت کنید»—هشداری مبنی بر اینکه کوکی در نسخه بعدی کروم مسدود خواهد شد .
- «به طور کامل به HTTPS مهاجرت کنید تا کوکیها در درخواستهای همان سایت ارسال شوند»—هشداری مبنی بر اینکه کوکی مسدود شده است .
مشکلات بارگذاری زیرمنابع:
- «برای ادامه ارسال کوکیها به زیرمنابع همان سایت، کاملاً به HTTPS مهاجرت کنید» یا «برای ادامه امکان تنظیم کوکیها توسط زیرمنابع همان سایت، کاملاً به HTTPS مهاجرت کنید»—هشدارهایی مبنی بر اینکه کوکی در نسخه بعدی کروم مسدود خواهد شد .
- «کاملاً به HTTPS مهاجرت کنید تا کوکیها به زیرمنابع همان سایت ارسال شوند» یا «کاملاً به HTTPS مهاجرت کنید تا کوکیها توسط زیرمنابع همان سایت تنظیم شوند» - هشدارهایی مبنی بر مسدود شدن کوکی. هشدار دوم همچنین میتواند هنگام ارسال فرم ظاهر شود.
جزئیات بیشتر در نکات تست و اشکالزدایی برای Schemeful Same-Site موجود است.
از فایرفاکس ۷۹، با تنظیم network.cookie.sameSite.schemeful روی true از طریق about:config کنسول پیامی را برای مشکلات Schemeful Same-Site نمایش میدهد. ممکن است موارد زیر را در سایت خود مشاهده کنید:
- «کوکی
cookie_nameبه زودی به عنوان کوکی بین سایتی در برابرhttp://site.example/در نظر گرفته خواهد شد زیرا این طرح مطابقت ندارد.» - «کوکی
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کاهش دهید.- اگر آدرس اینترنتی که کوکیها را به آن ارسال میکنید (یا آنها را از آن تنظیم میکنید) ناامن باشد، این راه حل با شکست مواجه خواهد شد. دلیل این امر آن است که
SameSite=Noneبه ویژگیSecureبرای کوکیها نیاز دارد، به این معنی که این کوکیها ممکن است از طریق یک اتصال ناامن ارسال یا تنظیم نشوند. در این صورت، تا زمانی که سایت شما به HTTPS ارتقا نیابد، نمیتوانید به آن کوکی دسترسی داشته باشید. - به یاد داشته باشید، این فقط موقتی است زیرا در نهایت کوکیهای شخص ثالث به طور کامل حذف خواهند شد.
- اگر آدرس اینترنتی که کوکیها را به آن ارسال میکنید (یا آنها را از آن تنظیم میکنید) ناامن باشد، این راه حل با شکست مواجه خواهد شد. دلیل این امر آن است که
اگر ویژگی SameSite را مشخص نکرده باشم، این موضوع چه تاثیری بر کوکیهای من خواهد داشت؟
کوکیهای بدون ویژگی SameSite طوری رفتار میشوند که انگار SameSite=Lax مشخص کردهاند و همان رفتار cross-scheme برای این کوکیها نیز اعمال میشود. توجه داشته باشید که استثنای موقت برای روشهای ناامن همچنان اعمال میشود، برای اطلاعات بیشتر به کاهش Lax + POST در سوالات متداول Chromium SameSite مراجعه کنید.
WebSockets چگونه تحت تأثیر قرار میگیرد؟
اتصالات WebSocket اگر از نظر امنیتی با صفحه یکسان باشند، همچنان به عنوان اتصالات same-site در نظر گرفته میشوند.
همان سایت:
- اتصال
wss://ازhttps:// - اتصال
ws://ازhttp://
بین سایتی:
- اتصال
wss://ازhttp:// - اتصال
ws://ازhttps://