หน้านี้ได้รับการแปลโดย Cloud Translation API

การเข้าถึงเครือข่ายส่วนตัว: แนะนำการตรวจสอบล่วงหน้า

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

อัปเดต

7 กรกฎาคม 2022: อัปเดตสถานะปัจจุบันและเพิ่มคำจำกัดความของพื้นที่ที่อยู่ IP
27 เมษายน 2022: ประกาศไทม์ไลน์ที่อัปเดต
7 มีนาคม 2022: ประกาศการย้อนกลับหลังจากพบปัญหาใน Chrome 98

บทนำ

Chrome จะเลิกใช้งานการเข้าถึงอุปกรณ์ปลายทางของเครือข่ายส่วนตัวโดยตรงจากเว็บไซต์สาธารณะตามข้อกําหนดของการเข้าถึงเครือข่ายส่วนตัว (PNA)

Chrome จะเริ่มส่งคำขอ CORS ล่วงหน้าก่อนคำขอเครือข่ายส่วนตัวสำหรับทรัพยากรย่อย ซึ่งจะขอสิทธิ์อย่างชัดเจนจากเซิร์ฟเวอร์เป้าหมาย คําขอก่อนการเรียกใช้นี้จะมีส่วนหัวใหม่ Access-Control-Request-Private-Network: true และการตอบกลับคําขอดังกล่าวต้องมีส่วนหัวที่สอดคล้องกัน Access-Control-Allow-Private-Network: true

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

แผนการเปิดตัว

Chrome จะทยอยเปิดตัวการเปลี่ยนแปลงนี้ใน 2 ระยะเพื่อให้เว็บไซต์มีเวลาสังเกตเห็นการเปลี่ยนแปลงและปรับเปลี่ยนตามความเหมาะสม

ใน Chrome 104
- Chrome ทำการทดสอบโดยการส่งคำขอ Preflight ก่อนคำขอทรัพยากรย่อยของเครือข่ายส่วนตัว
- การทำงานผิดพลาดก่อนการทดสอบจะแสดงคำเตือนในเครื่องมือสำหรับนักพัฒนาเว็บเท่านั้น โดยจะไม่ส่งผลต่อคำขอเครือข่ายส่วนตัว
- Chrome จะรวบรวมข้อมูลความเข้ากันได้และติดต่อเว็บไซต์ที่ได้รับผลกระทบมากที่สุด
- เราคาดว่าการอัปเดตนี้จะเข้ากันได้กับเว็บไซต์ที่มีอยู่โดยทั่วไป
คำเตือน: Chrome 104 จะจำกัดเวลาหมดอายุไว้ที่ 200 มิลลิวินาทีเพื่อจำกัดผลกระทบต่อเว็บไซต์ที่ไม่รองรับการเรียกใช้ข้อมูลพรอมต์ ข้อจำกัดจะมีผลเฉพาะในโหมดคำเตือน ระบบจะนำขีดจำกัดการหมดเวลาพิเศษออกหลังจากเปิดใช้โหมดบังคับใช้โดยเปลี่ยน "ใช้ผลลัพธ์ของการตรวจสอบสิทธิ์ก่อนเข้าถึงเครือข่ายส่วนตัว" เป็น "เปิดใช้" ใน chrome://flags และขีดจำกัดเริ่มต้นคือ 5 วินาที
ใน Chrome เวอร์ชัน 113 เป็นอย่างช้าที่สุด
- การดำเนินการนี้จะเริ่มต้นเฉพาะในกรณีที่ข้อมูลความเข้ากันได้ระบุว่าการเปลี่ยนแปลงนั้นปลอดภัยเพียงพอและเราได้ติดต่อไปโดยตรงเมื่อจำเป็น
- Chrome บังคับให้คำขอการตรวจสอบล่วงหน้าต้องสำเร็จ มิเช่นนั้นคำขอจะดำเนินการไม่สำเร็จ
- ช่วงทดลองใช้ฟีเจอร์ที่เลิกใช้งานจะเริ่มขึ้นพร้อมกันเพื่อให้เว็บไซต์ที่ได้รับผลกระทบจากระยะนี้ขอขยายเวลาได้ ช่วงทดลองใช้จะมีระยะเวลาอย่างน้อย 6 เดือน

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

การเข้าถึงเครือข่ายส่วนตัว (เดิมเรียกว่า CORS-RFC1918) จำกัดความสามารถของเว็บไซต์ในการส่งคำขอไปยังเซิร์ฟเวอร์ในเครือข่ายส่วนตัว

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

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

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

PNA จำแนกที่อยู่ IP และระบุเครือข่ายส่วนตัวอย่างไร

ที่อยู่ IP จะแบ่งออกเป็นพื้นที่ที่อยู่ IP 3 ประเภท ดังนี้ - public - private - local

พื้นที่ที่อยู่ IP ภายในประกอบด้วยที่อยู่ IP ที่เป็นที่อยู่ loopback ของ IPv4 (127.0.0.0/8) ที่ระบุไว้ในส่วนที่ 3.2.1.3 ของ RFC1122 หรือที่อยู่ loopback ของ IPv6 (::1/128) ที่ระบุไว้ในส่วนที่ 2.5.3 ของ RFC4291

พื้นที่ที่อยู่ IP ส่วนตัวประกอบด้วยที่อยู่ IP ที่มีความหมายเฉพาะภายในเครือข่ายปัจจุบัน ซึ่งรวมถึง 10.0.0.0/8, 172.16.0.0/12 และ 192.168.0.0/16 ที่ระบุไว้ใน RFC1918, ที่อยู่ภายในลิงก์ 169.254.0.0/16 ที่ระบุไว้ใน RFC3927, ที่อยู่ IPv6 แบบยูนิแคสต์ภายในที่ไม่ซ้ำกัน fc00::/7 ที่ระบุไว้ใน RFC4193, ที่อยู่ IPv6 แบบยูนิแคสต์ภายในลิงก์ fe80::/10 ที่ระบุไว้ในส่วนที่ 2.5.6 ของ RFC4291 และที่อยู่ IPv6 ที่แมปจาก IPv4 โดยที่ที่อยู่ IPv4 ที่แมปนั้นเป็นที่อยู่ส่วนตัว

พื้นที่ที่อยู่ IP สาธารณะประกอบด้วยที่อยู่อื่นๆ ทั้งหมดที่ไม่ได้กล่าวถึงก่อนหน้านี้

ที่อยู่ IP ในเครื่องถือว่ามีความเป็นส่วนตัวมากกว่าที่อยู่ IP ส่วนตัว ซึ่งถือว่ามีความเป็นส่วนตัวมากกว่าที่อยู่ IP สาธารณะ

คำขอจะเป็นแบบส่วนตัวเมื่อเครือข่ายที่มีความพร้อมมากกว่าส่งคำขอไปยังเครือข่ายที่มีความพร้อมน้อยกว่า — ความสัมพันธ์ระหว่างเครือข่ายสาธารณะ ส่วนตัว และเครือข่ายภายในในการเข้าถึงเครือข่ายส่วนตัว (CORS-RFC1918)

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

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

ข้อมูลเบื้องต้น

คําขอ Preflight เป็นกลไกที่มาตรฐาน Cross-Origin Resource Sharing (CORS) นำมาใช้เพื่อขอสิทธิ์จากเว็บไซต์เป้าหมายก่อนที่จะส่งคําขอ HTTP ที่อาจมีผลข้างเคียง วิธีนี้ช่วยให้มั่นใจว่าเซิร์ฟเวอร์เป้าหมายจะเข้าใจโปรโตคอล CORS และลดความเสี่ยงของการโจมตี CSRF ได้อย่างมีนัยสําคัญ

ระบบจะส่งคำขอสิทธิ์เป็นOPTIONSคำขอ HTTP ที่มีส่วนหัวคำขอ CORS ที่เฉพาะเจาะจง ซึ่งอธิบายคำขอ HTTP ที่กําลังจะเกิดขึ้น การตอบกลับต้องมีส่วนหัวการตอบกลับ CORS ที่เฉพาะเจาะจงซึ่งยอมรับคำขอที่กําลังจะส่งอย่างชัดเจน

ลำดับแผนภาพที่แสดงการตรวจสอบล่วงหน้าของ CORS ระบบจะส่งคําขอ OPTIONS HTTP ไปยังเป้าหมาย ซึ่งจะแสดงผลเป็น 200 OK จากนั้นระบบจะส่งส่วนหัวคำขอ CORS ซึ่งจะแสดงผลส่วนหัวการตอบกลับ CORS

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

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

Access-Control-Request-Private-Network: true ได้รับการตั้งค่าในคำขอการตรวจสอบล่วงหน้า PNA ทั้งหมด
ต้องตั้งค่า Access-Control-Allow-Private-Network: true ในการตอบกลับก่อนเที่ยวบิน PNA ทั้งหมด

ระบบจะส่งคำขอ Preflight สำหรับ PNA สำหรับคำขอเครือข่ายส่วนตัวทั้งหมด ไม่ว่าจะใช้วิธีการส่งคำขอและโหมดใดก็ตาม ระบบจะส่งคำขอเหล่านี้ก่อนคำขอในโหมด cors รวมถึงโหมด no-cors และโหมดอื่นๆ ทั้งหมด เนื่องจากคำขอเครือข่ายส่วนตัวทั้งหมดสามารถใช้สำหรับการโจมตี CSRF ได้ ไม่ว่าจะใช้โหมดคำขอใดและเนื้อหาการตอบกลับจะแสดงต่อผู้เริ่มหรือไม่ก็ตาม

หมายเหตุ: หากมีการส่งคำขอเครือข่ายส่วนตัวในโหมด cors จะต้องตั้งค่าส่วนหัว CORS ในการตอบกลับขั้นสุดท้าย นอกเหนือจากการตอบกลับการตรวจสอบล่วงหน้า

ระบบจะส่งคำขอ Preflight สำหรับ PNA สำหรับคำขอที่มีแหล่งที่มาเดียวกันด้วย หากที่อยู่ IP เป้าหมายมีความเป็นส่วนตัวมากกว่าคำขอเริ่มต้น ซึ่งแตกต่างจาก CORS ปกติที่คำขอการตรวจสอบล่วงหน้ามีไว้สำหรับคำขอข้ามแหล่งที่มาเท่านั้น คำขอการตรวจสอบก่อนเข้าสู่ระบบสำหรับคำขอจากแหล่งที่มาเดียวกันจะช่วยป้องกันการเชื่อมโยง DNS อีกครั้ง

ตัวอย่าง

ลักษณะการทำงานที่สังเกตได้จะขึ้นอยู่กับโหมดของคําขอ

โหมดไม่มี CORS

สมมติว่า https://foo.example/index.html ฝัง <img src="https://bar.example/cat.gif" alt="dancing cat"/> และ bar.example แสดงผลเป็น 192.168.1.1 ซึ่งเป็นที่อยู่ IP ส่วนตัวตาม RFC 1918

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

HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true

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

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true

คำเตือน: เซิร์ฟเวอร์สามารถตั้งค่า Access-Control-Allow-Origin: * ได้ แต่การดำเนินการนี้อันตรายและไม่แนะนำ แหล่งข้อมูลเครือข่ายส่วนตัวควรเข้าถึงได้ยากสำหรับต้นทางทั้งหมด ดังนั้นโปรดพิจารณาความเสี่ยงที่เกี่ยวข้องกับการตั้งค่าส่วนหัวดังกล่าวอย่างรอบคอบ

จากนั้น Chrome จะส่งคำขอจริง

HTTP/1.1 GET /cat.gif
...

ซึ่งเซิร์ฟเวอร์จะตอบกลับได้ตามปกติ

โหมด CORS

สมมติว่า https://foo.example/index.html เรียกใช้โค้ดต่อไปนี้

await fetch('https://bar.example/delete-everything', {
  method: 'PUT',
  credentials: 'include',
})

อีกครั้ง สมมติว่า bar.example เปลี่ยนเป็น 192.168.1.1

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

HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true

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

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true

จากนั้น Chrome จะส่งคำขอจริง

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

ซึ่งเซิร์ฟเวอร์จะตอบกลับได้ตามกฎ CORS ปกติ

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example

วิธีดูว่าเว็บไซต์ได้รับผลกระทบหรือไม่

ตั้งแต่ Chrome 104 เป็นต้นไป หากตรวจพบคำขอเครือข่ายส่วนตัว ระบบจะส่งคำขอ Preflight ไปก่อน หากคำขอก่อนการเรียกใช้นี้ไม่สำเร็จ ระบบจะยังคงส่งคำขอสุดท้าย แต่จะมีคำเตือนแสดงในแผงปัญหาของ DevTools

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

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

คำขอก่อนการเรียกใช้ที่ไม่สำเร็จในแผงเครือข่ายของเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์สำหรับ localhost ให้สถานะ 501

หากคําขอของคุณจะทริกเกอร์การตรวจสอบล่วงหน้าของ CORS ปกติโดยไม่มีกฎการเข้าถึงเครือข่ายส่วนตัว การตรวจสอบล่วงหน้า 2 รายการอาจปรากฏในแผงเครือข่าย โดยการตรวจสอบรายการแรกจะดูเหมือนว่าไม่สําเร็จเสมอ นี่เป็นข้อบกพร่องที่ทราบอยู่แล้ว คุณจึงไม่ต้องสนใจ

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

หากต้องการตรวจสอบสิ่งที่จะเกิดขึ้นหากมีการบังคับใช้การตรวจสอบก่อนการเรียกใช้ คุณสามารถส่งอาร์กิวเมนต์บรรทัดคำสั่งต่อไปนี้ได้ โดยเริ่มตั้งแต่ Chrome 98 เป็นต้นไป

--enable-features=PrivateNetworkAccessRespectPreflightResults

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

สิ่งที่ต้องทำหากเว็บไซต์ได้รับผลกระทบ

เมื่อการเปลี่ยนแปลงนี้เปิดตัวใน Chrome 104 เราไม่คาดว่าจะส่งผลกระทบต่อเว็บไซต์ใดๆ อย่างไรก็ตาม เราขอแนะนําอย่างยิ่งให้คุณอัปเดตเส้นทางคําขอที่ได้รับผลกระทบเพื่อให้เว็บไซต์ทํางานต่อไปได้ตามที่คาดไว้

เรามี 2 วิธีแก้ปัญหาให้คุณดังนี้

จัดการคําขอการตรวจสอบล่วงหน้าฝั่งเซิร์ฟเวอร์
ปิดใช้การตรวจสอบ PNA ด้วยนโยบายขององค์กร

จัดการคําขอการตรวจสอบล่วงหน้าฝั่งเซิร์ฟเวอร์

อัปเดตเซิร์ฟเวอร์เป้าหมายของการดึงข้อมูลใดๆ ที่ได้รับผลกระทบเพื่อจัดการคำขอเที่ยวบินก่อนออกเดินทางของ PNA ก่อนอื่น ให้ใช้การรองรับคำขอการตรวจสอบล่วงหน้า CORS มาตรฐานในเส้นทางที่ได้รับผลกระทบ จากนั้นเพิ่มการรองรับส่วนหัวการตอบกลับใหม่ 2 รายการ

เมื่อเซิร์ฟเวอร์ได้รับคําขอการตรวจสอบล่วงหน้า (คําขอ OPTIONS ที่มีส่วนหัว CORS) เซิร์ฟเวอร์ควรตรวจสอบว่ามีส่วนหัว Access-Control-Request-Private-Network: true หรือไม่ หากมีส่วนหัวนี้ในคำขอ เซิร์ฟเวอร์ควรตรวจสอบส่วนหัว Origin และเส้นทางคำขอพร้อมกับข้อมูลอื่นๆ ที่เกี่ยวข้อง (เช่น Access-Control-Request-Headers) เพื่อให้แน่ใจว่าคำขอนั้นปลอดภัยที่จะอนุญาต โดยทั่วไปแล้ว คุณควรอนุญาตให้เข้าถึงแหล่งที่มาเดียวภายใต้การควบคุมของคุณ

เมื่อเซิร์ฟเวอร์ตัดสินใจที่จะอนุญาตคําขอแล้ว ก็ควรตอบกลับ 204 No Content (หรือ 200 OK) ด้วยส่วนหัว CORS ที่จําเป็นและส่วนหัว PNA ใหม่ ส่วนหัวเหล่านี้ ได้แก่ Access-Control-Allow-Origin และ Access-Control-Allow-Private-Network: true รวมถึงส่วนหัวอื่นๆ ตามที่จำเป็น

ดูสถานการณ์จริงได้ที่ตัวอย่าง

ปิดใช้การตรวจสอบการเข้าถึงเครือข่ายส่วนตัวโดยใช้นโยบายขององค์กร

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

โปรดดูข้อมูลเพิ่มเติมที่หัวข้อทําความเข้าใจการจัดการนโยบาย Chrome

ให้ข้อเสนอแนะกับเรา

หากคุณโฮสต์เว็บไซต์ภายในเครือข่ายส่วนตัวที่คาดว่าจะได้รับคำขอจากเครือข่ายสาธารณะ ทีม Chrome ยินดีรับฟังความคิดเห็นและกรณีการใช้งานของคุณ โปรดแจ้งให้เราทราบโดยการรายงานปัญหาเกี่ยวกับ Chromium ที่ crbug.com และตั้งค่าคอมโพเนนต์เป็น Blink>SecurityFeature>CORS>PrivateNetworkAccess

ขั้นตอนถัดไป

ถัดไป Chrome จะขยายการตรวจสอบการเข้าถึงเครือข่ายส่วนตัวให้ครอบคลุมเวิร์กเกอร์ของเว็บ ซึ่งได้แก่ เวิร์กเกอร์เฉพาะ เวิร์กเกอร์ที่แชร์ และ Service Worker เราคาดว่า Chrome 107 จะเริ่มแสดงคำเตือน

จากนั้น Chrome จะขยายการตรวจสอบสิทธิ์เข้าถึงเครือข่ายส่วนตัวให้ครอบคลุมการไปยังส่วนต่างๆ ซึ่งรวมถึง iframe และป๊อปอัป เราคาดว่า Chrome 108 จะเริ่มแสดงคำเตือน

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

ขอขอบคุณ

รูปภาพปกโดย Mark Olsen จาก Unsplash