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

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 เป็น Private Network Access
  • เมษายน 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 ของเซิร์ฟเวอร์เป้าหมายเป็นส่วนตัวมากกว่าที่อยู่ 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 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 และกลไกการปักหมุดใบรับรองได้ ซึ่งช่วยให้สร้างการเชื่อมต่อที่ปลอดภัยกับอุปกรณ์ส่วนตัวที่อาจมีใบรับรองที่ลงนามด้วยตนเองได้ เป็นต้น การเชื่อมต่อ 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