ข้อมูลอัปเดตเกี่ยวกับการเข้าถึงเครือข่ายส่วนตัว: ขอแนะนำช่วงทดลองใช้การเลิกใช้งาน

Titouan Rigoudy
Titouan Rigoudy
Yifan Luo
Yifan Luo
GitHub

อัปเดต

  • 23 มีนาคม 2023: เราได้อัปเดตไทม์ไลน์แล้ว และจะไม่เลิกใช้งานจนกว่า Chrome 117 จะเปิดตัว

  • 19 มกราคม 2023: เราได้อัปเดตไทม์ไลน์แล้ว และจะไม่เลิกใช้งานจนกว่า Chrome 114 จะเปิดตัว

  • 12 สิงหาคม 2022: เราอัปเดตไทม์ไลน์แล้ว และการเลิกใช้งานจะไม่เกิดขึ้นจนกว่าจะถึง Chrome 109

  • 10 กุมภาพันธ์ 2022: บทความที่อัปเดตได้รับการเผยแพร่ในหัวข้อการเข้าถึงเครือข่ายส่วนตัว: การแนะนำการตรวจสอบล่วงหน้า

  • 25 สิงหาคม 2021: ประกาศไทม์ไลน์ที่อัปเดตและเปิดตัวช่วงทดลองเลิกใช้งาน

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

Chrome จะมีการเปลี่ยนแปลงต่อไปนี้

  • การบล็อกคำขอไปยังเครือข่ายส่วนตัวจากเว็บไซต์สาธารณะที่ไม่ปลอดภัยตั้งแต่ Chrome 94 เป็นต้นไป
  • ขอแนะนำช่วงทดลองใช้การเลิกใช้งานซึ่งจะสิ้นสุดใน Chrome
    1. ซึ่งจะช่วยให้นักพัฒนาแอปขอขยายเวลาสําหรับต้นทางที่เลือกได้ ซึ่งจะไม่ได้รับผลกระทบในระหว่างช่วงทดลองการเลิกใช้งาน
  • การแนะนำนโยบาย Chrome ซึ่งจะช่วยให้การติดตั้งใช้งาน Chrome ที่มีการจัดการสามารถข้ามการเลิกใช้งานไปอย่างถาวรได้ พร้อมใช้งานใน Chrome 92

หากต้องการเวลาเพิ่มเติมเพื่อลดผลกระทบจากการเลิกใช้งาน โปรดลงทะเบียนเข้าร่วมการทดลองเลิกใช้งาน

หากมีสิทธิ์ควบคุมผู้ใช้ในระดับผู้ดูแลระบบ คุณจะเปิดใช้ฟีเจอร์นี้อีกครั้งได้โดยใช้นโยบาย Chrome

หากต้องการลดผลกระทบจากข้อจํากัดใหม่ ให้ใช้กลยุทธ์ใดกลยุทธ์หนึ่งต่อไปนี้

ไทม์ไลน์

  • พฤศจิกายน 2020: ขอความคิดเห็นเกี่ยวกับการเปลี่ยนแปลงที่กําลังจะเกิดขึ้น
  • มีนาคม 2021: หลังจากตรวจสอบความคิดเห็นและการติดต่อ จะมีการประกาศการเปลี่ยนแปลงที่กําลังจะเกิดขึ้น ข้อมูลจำเพาะเปลี่ยนชื่อจาก CORS-RFC1918 เป็นการเข้าถึงเครือข่ายส่วนตัว
  • เมษายน 2021: Chrome 90 เปิดตัวไปยังเวอร์ชันเสถียรที่แสดงคำเตือนการเลิกใช้งาน
  • มิถุนายน 2021: Chrome 92 เปิดตัวเป็นเวอร์ชันเบต้า ซึ่งจะห้ามคำขอเครือข่ายส่วนตัวจากบริบทที่ไม่ปลอดภัย หลังจากได้รับความคิดเห็นจากนักพัฒนาแอปที่ขอเวลาเพิ่มเติมในการปรับตัว เราได้เลื่อนการเลิกใช้งานออกไปเป็น Chrome 93 พร้อมกับการทดลองเลิกใช้งาน
  • กรกฎาคม 2021: หลังจากได้รับความคิดเห็นเพิ่มเติมจากนักพัฒนาซอฟต์แวร์ เราจะเลื่อนการเลิกใช้งานและการทดลองใช้ที่เกี่ยวข้องไปไว้กับ Chrome 94 นอกจากนี้ เว็บไซต์ส่วนตัวจะไม่ได้รับผลกระทบจากการเลิกใช้งานอีกต่อไป
  • สิงหาคม 2021: Chrome 94 เปิดตัวในรุ่นเบต้า นักพัฒนาเว็บจะเริ่มลงชื่อสมัครใช้ ช่วงทดลองใช้การเลิกใช้งานได้
  • กันยายน 2021: Chrome 94 เปิดตัวไปยังเวอร์ชันเสถียร นักพัฒนาเว็บควรลงชื่อสมัครทดลองใช้การเลิกใช้งานและนำโทเค็นช่วงทดลองใช้ไปใช้งานกับเวอร์ชันที่ใช้งานจริง
  • ธันวาคม 2022: ส่งแบบสํารวจการทดลองใช้ Origin และได้รับความคิดเห็น การทดลองเลิกใช้งานจะขยายเวลาไปยัง Chrome เวอร์ชัน 113
  • มีนาคม 2023: ช่วงทดลองใช้การเลิกใช้งานจะขยายเวลาไปถึง Chrome 116 และจะสิ้นสุดใน Chrome 117 เรากําลังพัฒนากลไกทางเลือกที่อิงตามสิทธิ์เพื่อเปิดตัวครั้งแรกใน Chrome เวอร์ชัน 114
  • พฤษภาคม 2023 (โดยประมาณ): เปิดตัวกลไกที่อิงตามสิทธิ์ใน Chrome 114 เว็บไซต์สามารถใช้เพื่อออกจากช่วงทดลองใช้การเลิกใช้งาน
  • กันยายน 2023: Chrome 117 เปิดตัวเป็นเวอร์ชันเสถียร ซึ่งจะสิ้นสุดช่วงทดลองเลิกใช้งาน Chrome จะบล็อกคำขอเครือข่ายส่วนตัวทั้งหมดจากบริบทสาธารณะที่ไม่ปลอดภัย

การเข้าถึงเครือข่ายส่วนตัวคืออะไร

การเข้าถึงเครือข่ายส่วนตัว (ก่อนหน้านี้เรียกว่า CORS-RFC1918) จำกัดความสามารถของเว็บไซต์ในการส่งคำขอไปยังเซิร์ฟเวอร์ในเครือข่ายส่วนตัว โดยจะอนุญาตคำขอดังกล่าวจากบริบทที่ปลอดภัยเท่านั้น ข้อกำหนดนี้ยังขยายโปรโตคอลการแชร์ทรัพยากรข้ามโดเมน (CORS) ทำให้เว็บไซต์ต่างๆ ต้องส่งคำขออนุญาตอย่างชัดเจนจากเซิร์ฟเวอร์ในเครือข่ายส่วนตัวก่อนที่จะได้รับอนุญาตให้ส่งคำขอที่กำหนดเอง

คำขอเครือข่ายส่วนตัวเป็นคำขอที่ที่อยู่ IP ของเซิร์ฟเวอร์เป้าหมายมีความเป็นส่วนตัวมากกว่าคำขอที่ผู้เริ่มคำขอดึงข้อมูลมา เช่น คำขอจากเว็บไซต์สาธารณะ (https://example.com) ไปยังเว็บไซต์ส่วนตัว (http://router.local) หรือคำขอจากเว็บไซต์ส่วนตัวที่ส่งไปยัง localhost

ความสัมพันธ์ระหว่างเครือข่ายสาธารณะ ส่วนตัว และเครือข่าย LAN ในการเข้าถึงเครือข่ายส่วนตัว (CORS-RFC1918)
ความสัมพันธ์ระหว่างเครือข่ายสาธารณะ ส่วนตัว และภายในในการเข้าถึงเครือข่ายส่วนตัว (CORS-RFC1918)

ดูข้อมูลเพิ่มเติมได้ที่ต้องการความคิดเห็น: CORS สำหรับเครือข่ายส่วนตัว (RFC1918)

ช่วงทดลองใช้ฟีเจอร์ที่เลิกใช้งานคืออะไร

การทดสอบการเลิกใช้งาน (เดิมเรียกว่าการทดสอบการเลิกใช้งานแหล่งที่มาย้อนกลับ) เป็นการทดสอบแหล่งที่มารูปแบบหนึ่งที่ใช้เพื่อลดความซับซ้อนของการเลิกใช้งานฟีเจอร์ของเว็บ การทดลองเลิกใช้งานช่วยให้ Chrome เลิกใช้งานฟีเจอร์บางอย่างในเว็บและป้องกันไม่ให้เว็บไซต์สร้างการพึ่งพาใหม่ในฟีเจอร์เหล่านั้น ในขณะเดียวกันก็ให้เวลาเว็บไซต์ที่ยังคงใช้ฟีเจอร์ดังกล่าวอยู่ในการย้ายข้อมูล

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

ดูข้อมูลเพิ่มเติมได้ที่การเริ่มต้นใช้งานช่วงทดลองใช้จากต้นทางของ Chrome และคู่มือนักพัฒนาเว็บเกี่ยวกับช่วงทดลองใช้จากต้นทางเพื่อดูวิธีการ

การเปลี่ยนแปลงใน Chrome

Chrome 94

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

การเลิกใช้งานนี้มาพร้อมกับช่วงทดลองใช้การเลิกใช้งาน ซึ่งช่วยให้นักพัฒนาเว็บที่เว็บไซต์ใช้ฟีเจอร์ที่เลิกใช้งานแล้วสามารถใช้งานต่อไปได้จนถึง Chrome 116 โดยการลงทะเบียนรับโทเค็น ดูวิธีการลงทะเบียนและเปิดใช้ช่วงทดลองใช้บนเว็บไซต์ได้ที่ด้านล่าง

คุณสามารถใช้นโยบาย Chrome คู่หนึ่งเพื่อปิดใช้การเลิกใช้งานทั้งหมดหรือในต้นทางที่เฉพาะเจาะจงได้ โดยไม่มีกําหนด ซึ่งช่วยให้การติดตั้ง Chrome ที่มีการจัดการ เช่น การติดตั้งในองค์กร หลีกเลี่ยงการหยุดชะงักได้

Chrome 117

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

ขั้นตอนแรกสําหรับเว็บไซต์ที่ได้รับผลกระทบมีแนวโน้มที่จะซื้อเวลาจนกว่าจะมีการนำการแก้ไขที่เหมาะสมมาใช้ โดยลงทะเบียนช่วงทดลองการเลิกใช้งานหรือใช้นโยบาย จากนั้น แนวทางการดำเนินการที่แนะนำจะแตกต่างกันไปตามสถานการณ์ของเว็บไซต์แต่ละแห่งที่ได้รับผลกระทบ

ลงทะเบียนช่วงทดลองใช้ฟีเจอร์ที่เลิกใช้งาน

  1. คลิกลงทะเบียนเพื่อทดลองใช้การเข้าถึงเครือข่ายส่วนตัวจากต้นทางในบริบทที่ไม่ปลอดภัยเพื่อรับโทเค็นทดลองใช้สำหรับต้นทางที่เข้าร่วม
  2. เพิ่ม Origin-Trial: $token ที่เจาะจงแหล่งที่มาลงในส่วนหัวการตอบกลับ ส่วนหัวการตอบกลับนี้ต้องตั้งค่าเฉพาะในทรัพยากรหลักและการตอบกลับการนำทางเมื่อเอกสารผลลัพธ์ใช้ฟีเจอร์ที่เลิกใช้งานแล้วเท่านั้น การแนบส่วนหัวนี้กับการตอบสนองของทรัพยากรย่อยนั้นไม่มีประโยชน์ (แม้จะไม่เป็นอันตราย)

เนื่องจากต้องเปิดหรือปิดใช้ช่วงทดลองใช้นี้ก่อนจึงจะอนุญาตให้เอกสารส่งคำขอได้ จึงไม่สามารถเปิดใช้ผ่านแท็ก <meta> แท็กดังกล่าวจะได้รับการแยกวิเคราะห์จากเนื้อหาการตอบกลับหลังจากที่อาจมีการออกคำขอทรัพยากรย่อยแล้วเท่านั้น ปัญหานี้เกิดขึ้นกับเว็บไซต์ที่ไม่ได้ควบคุมส่วนหัวของคำตอบ เช่น เว็บไซต์แบบคงที่ของ github.io ที่แสดงโดยบุคคลที่สาม

โปรดดูรายละเอียดเพิ่มเติมในคู่มือนักพัฒนาเว็บเกี่ยวกับช่วงทดลองใช้ต้นทาง

เปิดใช้นโยบาย

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

โปรดดูรายละเอียดเพิ่มเติมเกี่ยวกับการจัดการนโยบายให้กับผู้ใช้ที่บทความในศูนย์ช่วยเหลือนี้

การเข้าถึง localhost

หากเว็บไซต์ต้องส่งคำขอไปยัง localhost คุณเพียงแค่ต้องอัปเกรดเว็บไซต์เป็น HTTPS

คำขอที่กำหนดเป้าหมาย http://localhost (หรือ http://127.*.*.*, http://[::1]) ไม่ถูกบล็อกโดยเนื้อหาผสม แม้ว่าจะออกมาจากบริบทที่ปลอดภัยก็ตาม

โปรดทราบว่าเครื่องมือ WebKit และเบราว์เซอร์ที่ใช้เครื่องมือนี้ (โดยเฉพาะ Safari) ไม่ได้เป็นไปตามข้อกำหนดเนื้อหาผสมของ W3C ที่นี่ และไม่อนุญาตให้ใช้คำขอเหล่านี้เป็นเนื้อหาผสม นอกจากนี้ เบราว์เซอร์ดังกล่าวยังไม่ใช้การเข้าถึงเครือข่ายส่วนตัว ดังนั้นเว็บไซต์อาจต้องการเปลี่ยนเส้นทางไคลเอ็นต์ที่ใช้เบราว์เซอร์ดังกล่าวไปยังเว็บไซต์เวอร์ชัน HTTP แบบข้อความธรรมดา ซึ่งเบราว์เซอร์ดังกล่าวจะยังคงส่งคำขอไปยัง localhost ได้

การเข้าถึงที่อยู่ IP ส่วนตัว

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

  • โปรดอัปเกรดทั้ง 2 เวอร์ชันเป็น HTTPS
  • ใช้ WebTransport เพื่อเชื่อมต่อกับเซิร์ฟเวอร์เป้าหมายอย่างปลอดภัย
  • ยกเลิกความสัมพันธ์การฝัง

อัปเกรดทั้ง 2 ฝั่งเป็น HTTPS

โซลูชันนี้ต้องใช้การควบคุมการแก้ไข DNS ของผู้ใช้ เช่น ในกรณีของบริบทอินทราเน็ต หรือในกรณีที่ผู้ใช้ได้รับที่อยู่เนมเซิร์ฟเวอร์จากเซิร์ฟเวอร์ DHCP ที่คุณควบคุม นอกจากนี้ คุณต้องมีชื่อโดเมนสาธารณะด้วย

ปัญหาหลักในการแสดงเว็บไซต์ส่วนตัวผ่าน HTTPS คือหน่วยงานออกใบรับรองโครงสร้างพื้นฐาน (PKI CA) ของคีย์สาธารณะจะจัดหาใบรับรอง TLS ให้กับเว็บไซต์ที่มีชื่อโดเมนสาธารณะเท่านั้น วิธีแก้ปัญหามีดังนี้

  1. จดทะเบียนชื่อโดเมนสาธารณะ (เช่น intranet.example) และเผยแพร่ระเบียน DNS ที่ชี้ชื่อโดเมนนั้นไปยังเซิร์ฟเวอร์สาธารณะที่คุณเลือก
  2. รับใบรับรอง TLS สำหรับ intranet.example
  3. ในเครือข่ายส่วนตัว ให้กําหนดค่า DNS เพื่อแก้ไข intranet.example เป็นที่อยู่ IP ส่วนตัวของเซิร์ฟเวอร์เป้าหมาย
  4. กำหนดค่าเซิร์ฟเวอร์ส่วนตัวเพื่อใช้ใบรับรอง TLS สำหรับ intranet.example ซึ่งจะช่วยให้ผู้ใช้เข้าถึงเซิร์ฟเวอร์ส่วนตัวที่ https://intranet.example ได้

จากนั้นอัปเกรดเว็บไซต์ที่เริ่มคําขอเป็น HTTPS และส่งคําขอต่อได้ตามปกติ

โซลูชันนี้ใช้ได้ในอนาคตและลดความเชื่อมั่นที่คุณมีต่อเครือข่าย โดยขยายการใช้การเข้ารหัสจากต้นทางถึงปลายทางภายในเครือข่ายส่วนตัว

WebTransport

โซลูชันนี้ไม่จำเป็นต้องควบคุมการแก้ไข DNS ของผู้ใช้ แต่เซิร์ฟเวอร์เป้าหมายต้องเรียกใช้เซิร์ฟเวอร์ WebTransport ขั้นต่ำ (เซิร์ฟเวอร์ HTTP/3 ที่มีการแก้ไขบางอย่าง)

คุณเลี่ยงการไม่มีใบรับรอง TLS ที่ถูกต้องซึ่งลงนามโดย CA ที่เชื่อถือได้ได้โดยใช้ WebTransport และกลไกการปักหมุดใบรับรอง ซึ่งช่วยให้สร้างการเชื่อมต่อที่ปลอดภัยกับอุปกรณ์ส่วนตัวที่อาจมีใบรับรองที่ลงนามด้วยตนเองได้ เป็นต้น การเชื่อมต่อ WebTransport อนุญาตให้มีการโอนข้อมูลแบบ 2 ทิศทาง แต่ไม่อนุญาตให้มีการส่งคำขอดึงข้อมูล คุณสามารถรวมวิธีการนี้กับ Service Worker เพื่อแสดงคำขอ HTTP พร็อกซีอย่างโปร่งใสผ่านการเชื่อมต่อ จากมุมมองของเว็บแอปพลิเคชัน ฝั่งเซิร์ฟเวอร์ เลเยอร์การแปลที่เกี่ยวข้องจะแปลงข้อความ WebTransport เป็นคำขอ HTTP ได้

เราทราบว่าการดำเนินการนี้เป็นงานที่มีปริมาณมากพอ แต่น่าจะง่ายกว่าการสร้างเพิ่มเติมบน WebRTC เป็นอย่างมาก และเรายังหวังด้วยว่าจะมีการใช้การลงทุนที่จำเป็นบางส่วนเป็นไลบรารีที่นำมาใช้ใหม่ได้ นอกจากนี้ เรายังเชื่อว่าการดำเนินการนี้คุ้มค่าอย่างยิ่งเมื่อพิจารณาจากข้อเท็จจริงที่ว่าบริบทที่ไม่ปลอดภัยมีแนวโน้มที่จะเสียสิทธิ์เข้าถึงฟีเจอร์ของแพลตฟอร์มเว็บมากขึ้นเรื่อยๆ เนื่องจากแพลตฟอร์มมุ่งส่งเสริมให้ใช้ HTTPS มากขึ้นเรื่อยๆ ไม่ว่าคุณจะเลือกการเข้าถึงเครือข่ายส่วนตัวหรือไม่ การลงทุนนี้น่าจะเป็นการลงทุนที่ชาญฉลาด

เราคาดว่า WebTransport ผ่าน HTTP/3 จะพร้อมใช้งานใน Chrome 96 (เริ่มการทดลองใช้จากต้นทางแล้ว) โดยมีมาตรการบรรเทาเพื่อปกป้องการแชร์คีย์และแนวทางปฏิบัติด้านความปลอดภัยที่ต่ำกว่ามาตรฐานอื่นๆ ซึ่งรวมถึง

  • เวลาหมดอายุสูงสุดสั้นๆ สำหรับใบรับรองที่ปักหมุดไว้
  • กลไกเฉพาะเบราว์เซอร์สำหรับการเพิกถอนคีย์บางรายการที่ถูกละเมิด

เราจะไม่เผยแพร่การจำกัดบริบทที่ปลอดภัยจนกว่าจะถึงเวลาอย่างน้อย 2 เป้าหมายหลังจากเปิดตัว WebTransport อย่างสมบูรณ์แล้ว เราจะขยายเวลาช่วงทดลองใช้การเลิกใช้งานหากจําเป็น

การฝังแบบย้อนกลับ

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

แทนที่จะดึงข้อมูลทรัพยากรย่อยส่วนตัวจากเว็บแอปสาธารณะ ระบบจะแสดงโครงของแอปจากเซิร์ฟเวอร์ส่วนตัว จากนั้นจึงดึงข้อมูลทรัพยากรย่อยทั้งหมด (เช่น สคริปต์หรือรูปภาพ) จากเซิร์ฟเวอร์สาธารณะ เช่น CDN จากนั้นเว็บแอปที่สร้างขึ้นจะส่งคำขอไปยังเซิร์ฟเวอร์ส่วนตัวได้ เนื่องจากถือว่ามีต้นทางเดียวกัน รวมถึงสามารถส่งคำขอไปยังเซิร์ฟเวอร์อื่นๆ ที่มี IP ส่วนตัว (แต่ไม่ใช่ localhost) ได้ด้วย แม้ว่าเรื่องนี้อาจเปลี่ยนแปลงในระยะยาว

เมื่อโฮสต์เฉพาะโครงบนเซิร์ฟเวอร์ส่วนตัว คุณจะอัปเดตเว็บแอปได้โดยการส่งทรัพยากรใหม่ไปยังเซิร์ฟเวอร์สาธารณะ เช่นเดียวกับการอัปเดตเว็บแอปสาธารณะ ในทางกลับกัน เว็บแอปที่ได้จะไม่ได้เป็นบริบทที่ปลอดภัย จึงไม่มีสิทธิ์เข้าถึงฟีเจอร์บางอย่างที่มีประสิทธิภาพมากขึ้นของเว็บ

แผนสำหรับอนาคต

การจำกัดคำขอเครือข่ายส่วนตัวให้อยู่ในบริบทที่ปลอดภัยเป็นเพียงขั้นตอนแรกในการเปิดใช้การเข้าถึงเครือข่ายส่วนตัว Chrome กำลังดำเนินการเพื่อติดตั้งใช้งานข้อกำหนดที่เหลือในอีกไม่กี่เดือนข้างหน้า โปรดติดตามข้อมูลอัปเดต

การจํากัดการเข้าถึง localhost จากเว็บไซต์ส่วนตัว

การเปลี่ยนแปลงใน Chrome 94 จะมีผลกับเว็บไซต์สาธารณะที่เข้าถึงที่อยู่ IP ส่วนตัวหรือ localhost เท่านั้น ข้อกำหนดการเข้าถึงเครือข่ายส่วนตัวยังจำแนกคำขอจากเว็บไซต์ส่วนตัวที่จะส่งไปยัง localhost ว่าเป็นปัญหาด้วย Chrome จะเลิกใช้งานคุกกี้เหล่านี้ด้วยเช่นกัน อย่างไรก็ตาม การดำเนินการนี้ก่อให้เกิดปัญหาที่แตกต่างออกไปเล็กน้อย เนื่องจากเว็บไซต์ส่วนตัวจำนวนมากไม่มีชื่อโดเมน ซึ่งทำให้การใช้โทเค็นช่วงทดลองการเลิกใช้งานมีความซับซ้อน

คำขอการตรวจสอบล่วงหน้าของ CORS

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

กล่าวโดยย่อคือ คำขอการตรวจสอบล่วงหน้าของ CORS คือคำขอ HTTP OPTIONS ที่มีส่วนหัว Access-Control-Request-* บางรายการซึ่งระบุลักษณะของคำขอที่ตามมา จากนั้นเซิร์ฟเวอร์จะตัดสินใจว่าจะให้สิทธิ์การเข้าถึงแบบละเอียดหรือไม่โดยตอบกลับ 200 OK ด้วยส่วนหัว Access-Control-Allow-*

ดูรายละเอียดเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ในข้อกำหนด

จำกัดการดึงข้อมูลการนำทาง

Chrome จะเลิกใช้งานและบล็อกคำขอทรัพยากรย่อยไปยังเครือข่ายส่วนตัวในที่สุด ซึ่งจะไม่ส่งผลต่อการไปยังเครือข่ายส่วนตัว ซึ่งอาจใช้ในการโจมตี CSRF ได้เช่นกัน

ข้อกําหนดการเข้าถึงเครือข่ายส่วนตัวไม่ได้แยกแยะการดึงข้อมูล 2 ประเภทนี้ ซึ่งสุดท้ายแล้วจะอยู่ภายใต้ข้อจํากัดเดียวกัน

รูปภาพปกโดย Markus Spiske จาก Unsplash