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

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 ระยะเพื่อให้เว็บไซต์มีเวลาสังเกตเห็นการเปลี่ยนแปลงและปรับเปลี่ยนตามความเหมาะสม

1. ใน Chrome 104

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

2. ใน Chrome เวอร์ชัน 113 เป็นอย่างช้าที่สุด

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

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

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

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

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

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 ส่วนตัว ซึ่งถือว่าเป็นส่วนตัวมากกว่าที่อยู่ IP สาธารณะ

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

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

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

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

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

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

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

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

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

ระบบจะส่งคำขอการตรวจสอบล่วงหน้าสำหรับ 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

จากนั้น 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

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

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

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

--enable-features=PrivateNetworkAccessRespectPreflightResults

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

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

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

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

1. จัดการคําขอการตรวจสอบล่วงหน้าฝั่งเซิร์ฟเวอร์
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 รวมถึงส่วนหัวอื่นๆ ตามที่จำเป็น

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

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

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

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

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

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

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

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

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

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

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

ขอขอบคุณ

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