ไซต์เดียวกันที่มีแผน

คำจำกัดความของ "เว็บไซต์เดียวกัน" มีการเปลี่ยนแปลงเพื่อรวมรูปแบบ URL ดังนั้นการลิงก์ระหว่างเวอร์ชัน HTTP และ HTTPS ของเว็บไซต์จึงนับเป็นคำขอข้ามเว็บไซต์ อัปเกรดเป็น HTTPS โดยค่าเริ่มต้นเพื่อหลีกเลี่ยงปัญหาที่เป็นไปได้ หรืออ่านต่อไปเพื่อดูรายละเอียดเกี่ยวกับค่าแอตทริบิวต์ SameSite ที่จำเป็น

สตีเวน บิงเลอร์
สตีเวน บิงเลอร์

รูปแบบ เว็บไซต์เดียวกัน แก้ไขคำจำกัดความของเว็บไซต์ (เว็บ) จากเฉพาะโดเมนที่จดทะเบียนได้ไปยัง รูปแบบ + โดเมนที่จดทะเบียนได้ ดูรายละเอียดและตัวอย่างเพิ่มเติมได้ในการทำความเข้าใจเกี่ยวกับ "เว็บไซต์เดียวกัน" และ "ต้นทางเดียวกัน"

ข่าวดีคือ หากเว็บไซต์ของคุณได้รับการอัปเกรดเป็น HTTPS โดยสมบูรณ์แล้ว คุณก็ไม่ต้องกังวลอะไรเลย โดยจะไม่มีการเปลี่ยนแปลงใดๆ เกิดขึ้น

หากคุณยังไม่ได้อัปเกรดเว็บไซต์อย่างเต็มรูปแบบ ก็ควรให้ความสำคัญกับเรื่องนี้ อย่างไรก็ตาม หากมีกรณีที่ผู้เข้าชมเว็บไซต์อยู่ระหว่าง HTTP กับ HTTPS สถานการณ์ที่พบบ่อยเหล่านั้นบางส่วนและลักษณะการทำงานของคุกกี้ SameSite ที่เกี่ยวข้องจะแสดงอยู่ด้านล่าง

คุณเปิดใช้การเปลี่ยนแปลงเหล่านี้สำหรับการทดสอบได้ทั้งใน Chrome และ Firefox

  • จาก 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 ที่ปลอดภัย SameSite=Strict คุกกี้ถูกบล็อก, SameSite=Lax และ SameSite=None อนุญาตให้ใช้คุกกี้ที่ปลอดภัย
การไปยังส่วนต่างๆ แบบข้ามรูปแบบจาก HTTP ไปยัง HTTPS
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ ถูกบล็อก ⛔ ถูกบล็อก
SameSite=Lax ✓ อนุญาต ✓ อนุญาต
SameSite=None;Secure ✓ อนุญาต ⛔ ถูกบล็อก

กำลังโหลดทรัพยากรย่อย

การเปลี่ยนแปลงที่คุณทำที่นี่ถือเป็นการแก้ไขชั่วคราวเท่านั้นระหว่างการอัปเกรดสู่ HTTPS เต็มรูปแบบ

ตัวอย่างของทรัพยากรย่อย ได้แก่ รูปภาพ, iframe และคำขอเครือข่ายที่สร้างด้วย XHR หรือ Fetch

การโหลดทรัพยากรย่อยแบบข้ามรูปแบบในหน้าเว็บจะทำให้สามารถส่งหรือตั้งค่าคุกกี้ SameSite=Strict หรือ SameSite=Lax ได้ก่อนหน้านี้ และตอนนี้ก็จะมีการดำเนินการในลักษณะเดียวกับทรัพยากรย่อยอื่นๆ ของบุคคลที่สามหรือข้ามเว็บไซต์ ซึ่งหมายความว่าคุกกี้ SameSite=Strict หรือ SameSite=Lax จะถูกบล็อก

นอกจากนี้ แม้ว่าเบราว์เซอร์จะอนุญาตให้โหลดทรัพยากรจากรูปแบบที่ไม่ปลอดภัยในหน้าเว็บที่ปลอดภัย แต่ระบบจะบล็อกคุกกี้ทั้งหมดในคำขอเหล่านี้เนื่องจากคุกกี้ของบุคคลที่สามหรือคุกกี้ข้ามเว็บไซต์ต้องใช้ Secure

ทรัพยากรย่อยแบบข้ามรูปแบบซึ่งเกิดจากทรัพยากรจากเว็บไซต์เวอร์ชัน HTTPS ที่ปลอดภัยที่รวมอยู่ในเวอร์ชัน HTTP ที่ไม่ปลอดภัย SameSite=Strict และ SameSite=Lax คุกกี้ถูกบล็อก และ SameSite=None อนุญาตให้ใช้คุกกี้ที่ปลอดภัย
หน้า HTTP ที่มีทรัพยากรย่อยแบบข้ามรูปแบบผ่าน HTTPS
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ ถูกบล็อก ⛔ ถูกบล็อก
SameSite=Lax ⛔ ถูกบล็อก ⛔ ถูกบล็อก
SameSite=None;Secure ✓ อนุญาต ⛔ ถูกบล็อก

การโพสต์แบบฟอร์ม

การโพสต์ระหว่างเว็บไซต์เวอร์ชันข้ามรูปแบบจะอนุญาตให้ส่งคุกกี้ที่ตั้งค่าด้วย SameSite=Lax หรือ SameSite=Strict ได้ก่อนหน้านี้ แต่ตอนนี้จะทำงานแบบ POST แบบข้ามเว็บไซต์ โดยจะส่งได้เฉพาะคุกกี้ SameSite=None เท่านั้น คุณอาจพบสถานการณ์นี้ในเว็บไซต์ที่แสดงเวอร์ชันที่ไม่ปลอดภัยโดยค่าเริ่มต้น แต่ให้อัปเกรดผู้ใช้เป็นเวอร์ชันที่ปลอดภัยเมื่อส่งฟอร์มลงชื่อเข้าใช้หรือชำระเงิน

เช่นเดียวกับทรัพยากรย่อย หากคำขอส่งจากที่ปลอดภัย เช่น HTTPS ไปยังที่ไม่ปลอดภัย เช่น บริบท HTTP คุกกี้ทั้งหมดจะถูกบล็อกในคำขอเหล่านี้เนื่องจากคุกกี้ของบุคคลที่สามหรือคุกกี้ข้ามเว็บไซต์ต้องใช้ Secure

การส่งแบบฟอร์มข้ามรูปแบบซึ่งเป็นผลมาจากแบบฟอร์มในเว็บไซต์เวอร์ชัน HTTP ที่ไม่ปลอดภัยซึ่งส่งไปยังเวอร์ชัน HTTPS ที่ปลอดภัย SameSite=Strict และ SameSite=Lax คุกกี้ถูกบล็อก และ SameSite=None อนุญาตให้ใช้คุกกี้ที่ปลอดภัย
การส่งแบบฟอร์มข้ามรูปแบบจาก HTTP ไปเป็น HTTPS
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ ถูกบล็อก ⛔ ถูกบล็อก
SameSite=Lax ⛔ ถูกบล็อก ⛔ ถูกบล็อก
SameSite=None;Secure ✓ อนุญาต ⛔ ถูกบล็อก

ฉันจะทดสอบเว็บไซต์ได้อย่างไร

เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์และการรับส่งข้อความพร้อมใช้งานใน Chrome และ Firefox แล้ว

แต่จาก Chrome 86 แท็บปัญหาใน DevTools จะมีปัญหา Schemeful Same-Site รวมอยู่ด้วย คุณอาจเห็นปัญหาต่อไปนี้ที่ไฮไลต์ สำหรับเว็บไซต์ของคุณ

ปัญหาเกี่ยวกับการนําทาง

  • "ย้ายข้อมูลทั้งหมดไปยัง HTTPS เพื่อให้มีการส่งคุกกี้ในคำขอของเว็บไซต์เดียวกันต่อไป" - คำเตือนว่าคุกกี้จะถูกบล็อกใน Chrome เวอร์ชันในอนาคต
  • "ย้ายข้อมูลทั้งหมดไปยัง HTTPS เพื่อให้มีการส่งคุกกี้ในคำขอของเว็บไซต์เดียวกัน" - คำเตือนว่าคุกกี้ถูกบล็อกแล้ว

ปัญหาการโหลดทรัพยากรย่อย:

  • "ย้ายข้อมูลทั้งหมดไปยัง HTTPS เพื่อให้ส่งคุกกี้ไปยังทรัพยากรย่อยในเว็บไซต์เดียวกันต่อไป" หรือ "ย้ายข้อมูลทั้งหมดไปยัง HTTPS เพื่ออนุญาตให้ทรัพยากรย่อยในเว็บไซต์เดียวกันตั้งค่าคุกกี้ต่อไป" - คำเตือนว่าคุกกี้จะบล็อกใน Chrome เวอร์ชันในอนาคต
  • "ย้ายข้อมูลทั้งหมดไปยัง HTTPS เพื่อให้ส่งคุกกี้ไปยังทรัพยากรย่อยในเว็บไซต์เดียวกัน" หรือ "ย้ายข้อมูลไปยัง HTTPS ทั้งหมดเพื่ออนุญาตให้ทรัพยากรย่อยในเว็บไซต์เดียวกันตั้งค่าคุกกี้" - คำเตือนว่าคุกกี้ถูกบล็อกไว้ คำเตือนหลังอาจปรากฏขึ้นเมื่อโพสต์แบบฟอร์ม

ดูรายละเอียดเพิ่มเติมได้ในเคล็ดลับการทดสอบและแก้ไขข้อบกพร่องสำหรับ Schemeful Same-Site

จาก Firefox 79 โดยตั้งค่า network.cookie.sameSite.schemeful เป็น true ผ่าน about:config คอนโซลจะแสดงข้อความสำหรับปัญหาเกี่ยวกับ Schemeful Same-Site คุณอาจเห็นสิ่งต่อไปนี้บนเว็บไซต์ของคุณ

  • "ระบบจะถือว่าคุกกี้ cookie_name เร็วๆ นี้ เป็นคุกกี้ข้ามเว็บไซต์กับ http://site.example/ เนื่องจากรูปแบบไม่ตรงกัน"
  • "คุกกี้cookie_name ได้รับถือว่าข้ามเว็บไซต์กับhttp://site.example/เนื่องจากรูปแบบไม่ตรงกัน"

คำถามที่พบบ่อย

เว็บไซต์ของฉันพร้อมใช้งานอย่างเต็มรูปแบบบน HTTPS แล้ว เหตุใดฉันจึงเห็นปัญหาในเครื่องมือสำหรับนักพัฒนาเว็บของเบราว์เซอร์

อาจเป็นไปได้ว่าลิงก์และทรัพยากรย่อยบางส่วนของคุณยังคงชี้ไปยัง 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
    • โปรดทราบว่าปัญหานี้เกิดขึ้นเพียงชั่วคราวเท่านั้น เนื่องจากคุกกี้ของบุคคลที่สามจะเลิกใช้งานอย่างสมบูรณ์ในที่สุด

การดําเนินการนี้จะส่งผลต่อคุกกี้ของฉันอย่างไร หากฉันยังไม่ได้ระบุแอตทริบิวต์ SameSite

คุกกี้ที่ไม่มีแอตทริบิวต์ SameSite จะได้รับการดำเนินการเหมือนกับที่ระบุ SameSite=Lax และลักษณะการทำงานแบบข้ามรูปแบบจะมีผลกับคุกกี้เหล่านี้ด้วยเช่นกัน โปรดทราบว่าข้อยกเว้นชั่วคราวสำหรับวิธีการที่ไม่ปลอดภัยยังคงมีผล โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการบรรเทาปัญหา Lax + POST ในSameSiteคำถามที่พบบ่อยของ Chromium

WebSocket ได้รับผลกระทบอย่างไร

การเชื่อมต่อ WebSocket จะยังถือว่าเป็นเว็บไซต์เดียวกันหากมีความปลอดภัยระดับเดียวกับหน้าเว็บ

เว็บไซต์เดียวกัน:

  • การเชื่อมต่อ wss:// จาก https://
  • การเชื่อมต่อ ws:// จาก http://

ข้ามเว็บไซต์:

  • การเชื่อมต่อ wss:// จาก http://
  • การเชื่อมต่อ ws:// จาก https://

รูปภาพโดย Julissa Capdevilla ใน Unsplash