อัปเดต
- 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 เวอร์ชัน 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 วิธีแก้ปัญหาให้คุณดังนี้
- จัดการคําขอการตรวจสอบล่วงหน้าฝั่งเซิร์ฟเวอร์
- ปิดใช้การตรวจสอบ 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 จะเริ่มแสดงคำเตือน
ในทั้ง 2 กรณี เราจะดำเนินการด้วยความระมัดระวังโดยการเปิดตัวเป็นระยะๆ ที่คล้ายกัน เพื่อให้นักพัฒนาเว็บมีเวลาในการปรับและประเมินความเสี่ยงด้านความเข้ากันได้
ขอขอบคุณ
รูปภาพปกโดย Mark Olsen จาก Unsplash