คำจำกัดความของ "เว็บไซต์เดียวกัน" มีการพัฒนาเพื่อรวมรูปแบบ URL ดังนั้นลิงก์ระหว่างเวอร์ชัน HTTP และ HTTPS ของเว็บไซต์ในขณะนี้จะนับเป็นคำขอข้ามเว็บไซต์ อัปเกรดเป็น HTTPS โดยค่าเริ่มต้นเพื่อหลีกเลี่ยงปัญหาหากทำได้ หรืออ่านรายละเอียดเกี่ยวกับค่าแอตทริบิวต์ SameSite ที่จำเป็น
มีเสน่ห์ เว็บไซต์เดียวกัน แก้ไขคำจำกัดความของเว็บไซต์ (เว็บ) จากโดเมนที่จดทะเบียนได้เป็น Scheme + โดเมนที่จดทะเบียนได้ ดูรายละเอียดและตัวอย่างเพิ่มเติมได้ใน การทำความเข้าใจ "เว็บไซต์เดียวกัน" และ "same-origin"
ข่าวดีก็คือ หากเว็บไซต์ของคุณได้รับการอัปเกรดเป็น HTTPS โดยสมบูรณ์แล้ว คุณจะ ไม่ต้องกังวล จะไม่มีการเปลี่ยนแปลงใดๆ สำหรับคุณ
หากคุณยังไม่ได้อัปเกรดเว็บไซต์อย่างเต็มรูปแบบ ควรให้ความสำคัญเป็นลำดับแรก
อย่างไรก็ตาม หากมีกรณีที่ผู้เข้าชมเว็บไซต์จะสลับใช้ HTTP กับ
HTTPS แล้วตามด้วยสถานการณ์ที่พบบ่อยบางส่วนและคุกกี้ SameSite
ที่เกี่ยวข้อง
ดังแสดงไว้ด้านล่างนี้
คุณสามารถเปิดใช้งานการเปลี่ยนแปลงเหล่านี้สำหรับการทดสอบทั้งใน 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 ที่ปลอดภัยของ
ของคุณ การสร้างขอบเขตข้ามเว็บไซต์เพิ่มเติมระหว่างรูปแบบจะให้
ป้องกันการโจมตีเหล่านี้ได้มากขึ้น
สถานการณ์ที่พบได้บ่อยในหลายช่องทาง
การนำทาง
การสลับไปมาระหว่างเว็บไซต์เวอร์ชันแบบข้ามรูปแบบ (เช่น การลิงก์จาก
http://site.example ไปยัง https://site.example) จะอนุญาตก่อนหน้านี้
คุกกี้ SameSite=Strict
รายการที่จะส่ง ขณะนี้ระบบจะถือว่าเป็นแบบข้ามเว็บไซต์
ซึ่งหมายความว่าคุกกี้ SameSite=Strict
จะถูกบล็อก
![การนำทางแบบข้ามรูปแบบที่ทริกเกอร์โดยการติดตามลิงก์บนเว็บไซต์เวอร์ชัน HTTP ที่ไม่ปลอดภัยไปยังเวอร์ชัน HTTPS ที่ปลอดภัย SameSite=Strict คุกกี้ที่ถูกบล็อก, SameSite=Lax และ SameSite=None; อนุญาตคุกกี้ที่ปลอดภัย](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-navigation-209071cf80318.png?authuser=5&hl=th)
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 cookies blocked และ SameSite=None; อนุญาตคุกกี้ที่ปลอดภัย](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-subresourc-ee291fec730b8.png?authuser=5&hl=th)
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 cookies blocked และ SameSite=None; อนุญาตคุกกี้ที่ปลอดภัย](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-form-submi-528e4c1eb4c83.png?authuser=5&hl=th)
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 - โปรดทราบว่านี่เป็นเพียงการดำเนินการชั่วคราวเพราะท้ายที่สุดแล้วคุกกี้ของบุคคลที่สามจะ ถูกตัดออกไปอย่างสิ้นเชิง
- วิธีแก้ปัญหาเบื้องต้นนี้จะล้มเหลวหาก URL ที่คุณส่งคุกกี้ไป (หรือ
ที่ตั้งค่าจาก) ไม่ปลอดภัย เนื่องจาก
การเลือกนี้จะส่งผลต่อคุกกี้ของฉันอย่างไรหากฉันไม่ได้ระบุแอตทริบิวต์ SameSite
คุกกี้ที่ไม่มีแอตทริบิวต์ SameSite
จะถือว่าเป็นคุกกี้ที่ระบุ
SameSite=Lax
และการทำงานข้ามรูปแบบเดียวกันจะใช้กับคุกกี้เหล่านี้ด้วย
โปรดทราบว่ายังคงมีข้อยกเว้นชั่วคราวสำหรับวิธีที่ไม่ปลอดภัย โปรดดู
การลด Lax + POST ใน Chromium SameSite
คำถามที่พบบ่อยเพื่อดูข้อมูลเพิ่มเติม
WebSocket จะได้รับผลกระทบอย่างไร
การเชื่อมต่อ WebSocket จะยังถือว่าเป็นเว็บไซต์เดียวกันหากเป็นการเชื่อมต่อเดียวกัน ความปลอดภัยเท่ากับหน้าเว็บ
เว็บไซต์เดียวกัน:
- การเชื่อมต่อ
wss://
จากhttps://
- การเชื่อมต่อ
ws://
จากhttp://
ข้ามเว็บไซต์:
- การเชื่อมต่อ
wss://
จากhttp://
- การเชื่อมต่อ
ws://
จากhttps://
ภาพโดย Julissa แคปเดวิลลา ในวันที่ หน้าจอแนะนํา