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

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

Steven Bingler

Rowan Merewood

หมายเหตุ: บทความนี้เป็นส่วนหนึ่งของชุดการเปลี่ยนแปลงแอตทริบิวต์คุกกี้ SameSite ซึ่งประกอบด้วยสิ่งต่อไปนี้

• ทำความเข้าใจเกี่ยวกับคุกกี้
• คำอธิบายเกี่ยวกับคุกกี้ SameSite
• สูตรคุกกี้ SameSite

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

คำสำคัญ: ซึ่งหมายความว่าเวอร์ชัน HTTP ที่ไม่ปลอดภัยของเว็บไซต์ เช่น http://website.example และเวอร์ชัน HTTPS ที่ปลอดภัยของเว็บไซต์นั้น ซึ่งคือ https://website.example จะถือว่ากันและกันเป็นแบบข้ามเว็บไซต์

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

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

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

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

• เปิดใช้ about://flags/#schemeful-same-site จาก Chrome 86 ติดตามความคืบหน้า ในสถานะของ Chrome
• จาก Firefox 79 ให้ตั้งค่า network.cookie.sameSite.schemeful เป็น true ผ่าน about:config ติดตามความคืบหน้าผ่าน Bigzilla ปัญหา

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

สถานการณ์ที่พบได้บ่อยในหลายช่องทาง

คำสำคัญ: ในตัวอย่างด้านล่างซึ่ง URL ทั้งหมดมีโดเมนที่จดทะเบียนได้เหมือนกัน เช่น site.example แต่รูปแบบที่ต่างกัน เช่น http://site.example กับ https://site.example จะเรียกกันและกันว่า cross-scheme

การนำทาง

การสลับไปมาระหว่างเว็บไซต์เวอร์ชันแบบข้ามรูปแบบ (เช่น การลิงก์จาก http://site.example ไปยัง https://site.example) จะอนุญาตก่อนหน้านี้ คุกกี้ SameSite=Strict รายการที่จะส่ง ขณะนี้ระบบจะถือว่าเป็นแบบข้ามเว็บไซต์ ซึ่งหมายความว่าคุกกี้ SameSite=Strict จะถูกบล็อก

วันที่

การนำทางข้ามรูปแบบจาก HTTP ไปยัง HTTPS

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ ถูกบล็อก	⛔ ถูกบล็อก
SameSite=Lax	✓ อนุญาต	✓ อนุญาต
SameSite=None;Secure	✓ อนุญาต	⛔ ถูกบล็อก

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

คำเตือน: เบราว์เซอร์หลักทั้งหมดจะบล็อกเนื้อหาผสมที่ใช้งานอยู่ เช่น สคริปต์หรือ iframe นอกจากนี้ เบราว์เซอร์ซึ่งรวมถึง Chrome และ Firefox กำลังพยายามอัปเกรดหรือบล็อกเนื้อหาผสมแบบแพสซีฟ

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

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

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

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

วันที่

หน้า HTTP ที่มีทรัพยากรย่อยข้ามรูปแบบผ่าน HTTPS

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ ถูกบล็อก	⛔ ถูกบล็อก
SameSite=Lax	⛔ ถูกบล็อก	⛔ ถูกบล็อก
SameSite=None;Secure	✓ อนุญาต	⛔ ถูกบล็อก

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

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

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

คำเตือน: วิธีแก้ไขที่ดีที่สุดคือตรวจสอบว่าทั้งหน้าแบบฟอร์มและปลายทางใช้การเชื่อมต่อที่ปลอดภัย เช่น HTTPS ซึ่งสำคัญมากในกรณีที่ผู้ใช้ป้อนข้อมูลที่ละเอียดอ่อนในแบบฟอร์ม

การส่งแบบฟอร์มข้ามรูปแบบจาก HTTP ไปยัง HTTPS

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ ถูกบล็อก	⛔ ถูกบล็อก
SameSite=Lax	⛔ ถูกบล็อก	⛔ ถูกบล็อก
SameSite=None;Secure	✓ อนุญาต	⛔ ถูกบล็อก

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

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

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

ปัญหาการนำทาง

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

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

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

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

จาก 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 การรักษาความปลอดภัยในการขนส่งแบบเข้มงวด (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 ใน Chromium SameSite คำถามที่พบบ่อยเพื่อดูข้อมูลเพิ่มเติม

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

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

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

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

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

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

ภาพโดย Julissa แคปเดวิลลา ในวันที่ หน้าจอแนะนํา