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

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

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

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

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

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

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

ที่อยู่ IP ได้รับการจัดประเภทเป็นช่องว่างในที่อยู่ IP สามรายการดังนี้ - public - private ครั้ง - local

พื้นที่ที่อยู่ IP ภายในมีที่อยู่ IP ที่เป็น IPv4 ที่อยู่ Loopback (127.0.0.0/8) ที่กำหนดไว้ในส่วน 3.2.1.3 ของ RFC1122 หรือที่อยู่ IPv6 Loopback (::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 แบบ Unicast ในเครื่องที่ไม่ซ้ำกัน fc00::/7 ซึ่งระบุไว้ใน RFC4193 ที่อยู่ IPv6 แบบ Unicast ที่ลิงก์ภายใน fe80::/10 ระบุไว้ในส่วนที่ 2.5.6 ของ RFC4291 และที่อยู่ IPv6 ที่แมปด้วย IPv4 โดยที่อยู่ IPv4 ที่แมปจะเป็นส่วนตัว

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ตัวอย่าง

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

โหมดไม่มี 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 เป็นต้นไป หากตรวจพบคำขอเครือข่ายส่วนตัว การตรวจสอบล่วงหน้า คำขอจะส่งไปก่อน หากคำขอการตรวจสอบล่วงหน้านี้ไม่สำเร็จ ระบบจะเลือก ระบบจะยังคงส่งคำขอต่อไป แต่คำเตือนจะปรากฏในเครื่องมือสำหรับนักพัฒนาเว็บ ปัญหา

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

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

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

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

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

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

--enable-features=PrivateNetworkAccessRespectPreflightResults

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

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

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

คุณมีโซลูชัน 2 แบบดังนี้

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

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

อัปเดตเซิร์ฟเวอร์เป้าหมายของการดึงข้อมูลที่ได้รับผลกระทบเพื่อจัดการการตรวจสอบล่วงหน้าสำหรับ PNA คำขอ ข้อที่ 1 เปิดใช้การรองรับคำขอการตรวจสอบล่วงหน้าสำหรับ 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 จะขยายการตรวจสอบการเข้าถึงเครือข่ายส่วนตัวให้ครอบคลุม ผู้ปฏิบัติงานบนเว็บ: ผู้ปฏิบัติงานเฉพาะกิจ ผู้ปฏิบัติงานที่แชร์ และผู้ปฏิบัติงานบริการ เราคาดว่า สำหรับ Chrome 107 เพื่อเริ่มแสดงคำเตือน

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

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

กิตติกรรมประกาศ

รูปภาพปกโดย Mark Olsen ใน หน้าจอแนะนํา