ข้อมูลอัปเดต
- 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 จะรวบรวมข้อมูลความเข้ากันได้และเข้าถึงเว็บไซต์ที่ใหญ่ที่สุดที่ได้รับผลกระทบ
- เราคาดว่าฟีเจอร์นี้จะเข้ากันได้กับเว็บไซต์ที่มีอยู่ในวงกว้าง
ใน Chrome 113 เวอร์ชันแรกสุด
- การดำเนินการนี้จะเริ่มต้นก็ต่อเมื่อข้อมูลความเข้ากันได้ระบุว่าการเปลี่ยนแปลงปลอดภัยเพียงพอ และเราได้ติดต่อโดยตรงเมื่อจำเป็น
- Chrome จะบังคับให้คำขอการตรวจสอบล่วงหน้าต้องประสบความสำเร็จ มิเช่นนั้นคำขอจะไม่สำเร็จ
- ช่วงทดลองเลิกใช้งานจะเริ่มพร้อมกันเพื่อให้เว็บไซต์ที่ได้รับผลกระทบจากระยะนี้ขอขยายเวลาได้ ช่วงทดลองใช้จะมีระยะเวลาอย่างน้อย 6 เดือน
การเข้าถึงเครือข่ายส่วนตัว (PNA) คืออะไร
การเข้าถึงเครือข่ายส่วนตัว (เดิมชื่อ CORS-RFC1918) จำกัดความสามารถของเว็บไซต์ในการส่งคำขอไปยังเซิร์ฟเวอร์ในเครือข่ายส่วนตัว
Chrome ได้ใช้ข้อกำหนดบางส่วนแล้ว นับตั้งแต่ Chrome 96 เป็นต้นไป เฉพาะบริบทที่ปลอดภัยเท่านั้นที่ได้รับอนุญาตให้ส่งคำขอเครือข่ายส่วนตัว ดูรายละเอียดได้จากบล็อกโพสต์ก่อนหน้า
ข้อกำหนดนี้ยังขยายโปรโตคอลการแชร์ทรัพยากรข้ามโดเมน (CORS) ด้วย เพื่อให้เว็บไซต์ต้องขอการให้สิทธิ์จากเซิร์ฟเวอร์ในเครือข่ายส่วนตัวอย่างชัดแจ้งก่อนที่จะได้รับอนุญาตให้ส่งคำขอที่กำหนดเอง
PNA จัดประเภทที่อยู่ IP และระบุเครือข่ายส่วนตัวอย่างไร
ที่อยู่ IP จะแบ่งเป็นช่องว่างของที่อยู่ IP อยู่ 3 แบบ ดังนี้
- public
- private
- local
พื้นที่ของที่อยู่ IP ภายในมีที่อยู่ IP ที่เป็นที่อยู่ IP แบบวนกลับ (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 ที่อยู่ IPv4 ส่วนตัวแบบลิงก์ จับคู่ที่อยู่ IPv6 ภายในตัวแล้ว {13 IPv6 ยูนิแคสต์ 2/ลิงก์} RFC4193 ที่แมปไว้ในส่วนที่อยู่ IPv4 ส่วนตัวและลิงก์ภายใน fe80::/10RFC4291
พื้นที่ที่อยู่ IP สาธารณะมีที่อยู่อื่นๆ ทั้งหมดที่ไม่ได้กล่าวถึงก่อนหน้านี้
ที่อยู่ IP ของเครื่องจะถือว่ามีความเป็นส่วนตัวมากกว่าที่อยู่ IP ส่วนตัว ซึ่งถือว่าเป็นส่วนตัวมากกว่าที่อยู่ IP สาธารณะ
ดูข้อมูลเพิ่มเติมได้ที่ต้องการแสดงความคิดเห็น: CORS สำหรับเครือข่ายส่วนตัว (RFC1918)
คำขอการตรวจสอบล่วงหน้า
ที่มา
คำขอการตรวจสอบล่วงหน้าเป็นกลไกของมาตรฐานการแชร์ทรัพยากรข้ามต้นทาง (CORS) ที่ใช้ในการขอสิทธิ์จากเว็บไซต์เป้าหมายก่อนที่จะส่งคำขอ HTTP ที่อาจมีผลข้างเคียง วิธีนี้ช่วยให้เซิร์ฟเวอร์เป้าหมายเข้าใจโปรโตคอล CORS และลดความเสี่ยงจากการโจมตี CSRF ได้อย่างมาก
ระบบจะส่งคำขอสิทธิ์เป็นคำขอ HTTP OPTIONS พร้อมส่วนหัวของคำขอ CORS ที่เจาะจงซึ่งอธิบายคำขอ HTTP ที่กำลังจะมาถึง การตอบกลับต้องมีส่วนหัวการตอบกลับ CORS ที่เจาะจงเพื่อยอมรับคำขอที่กำลังจะมาถึงอย่างชัดแจ้ง
มีอะไรใหม่ในการเข้าถึงเครือข่ายส่วนตัว
คำขอและส่วนหัวการตอบกลับคู่ใหม่จะแนะนำในคำขอการตรวจสอบล่วงหน้า
- มีการตั้งค่า
Access-Control-Request-Private-Network: trueในคำขอการตรวจสอบล่วงหน้าสำหรับ PNA ทั้งหมด - ต้องตั้งค่า
Access-Control-Allow-Private-Network: trueในการตอบกลับการตรวจสอบล่วงหน้าสำหรับ PNA ทั้งหมด
ระบบจะส่งคำขอการตรวจสอบล่วงหน้าสำหรับ PNA สำหรับคำขอเครือข่ายส่วนตัวทั้งหมด โดยไม่คำนึงถึงวิธีการส่งคำขอและโหมด ระบบจะส่งคำขอล่วงหน้าในโหมด cors รวมถึง no-cors และโหมดอื่นๆ ทั้งหมด เนื่องจากคำขอเครือข่ายส่วนตัวทั้งหมดสามารถใช้สำหรับการโจมตี CSRF ได้ ไม่ว่าโหมดคำขอจะเป็นแบบใดก็ตาม และไม่ว่าเนื้อหาการตอบกลับจะพร้อมให้ใช้งานกับผู้เริ่มหรือไม่ก็ตาม
ระบบจะส่งคำขอการตรวจสอบล่วงหน้าสำหรับ 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
จากนั้น 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 เป็นต้นไป หากตรวจพบคำขอเครือข่ายส่วนตัว ระบบจะส่งคำขอการตรวจสอบล่วงหน้าก่อนคำขอนั้น หากคำขอการตรวจสอบล่วงหน้านี้ไม่สำเร็จ ระบบจะยังคงส่งคำขอสุดท้าย แต่คำเตือนจะปรากฏในแผงปัญหาของเครื่องมือสำหรับนักพัฒนาเว็บ
คุณยังดูและวินิจฉัยคำขอก่อนการตรวจสอบที่ได้รับผลกระทบในแผงเครือข่ายได้ด้วย โดยทำดังนี้
หากคำขอของคุณทริกเกอร์การตรวจสอบล่วงหน้าสำหรับ 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