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

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: ส่งแบบสำรวจและแสดงความคิดเห็นเกี่ยวกับช่วงทดลองใช้จากต้นทางแล้ว เราจะขยายช่วงทดลองใช้การเลิกใช้งานไปยัง 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

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

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

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

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

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

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

มีอะไรเปลี่ยนแปลงใน Chrome

Chrome 94

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

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

นโยบาย Chrome 2 ชุดจะนำมาใช้เพื่อปิดใช้การเลิกใช้งานทั้งหมดหรือเฉพาะบางต้นทางได้โดยไม่มีกำหนด การดำเนินการนี้จะทำให้การติดตั้ง 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 และกลไกการปักหมุดใบรับรอง วิธีนี้ช่วยให้สร้างการเชื่อมต่อที่ปลอดภัยกับอุปกรณ์ส่วนตัวที่อาจมีใบรับรองแบบ Self-signed เป็นต้น การเชื่อมต่อ 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

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

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

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

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

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

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

รูปภาพปกโดย markus Spiske ใน Unsplash