ลดความเสี่ยงที่เกี่ยวข้องกับการเปิดเผยอุปกรณ์และเซิร์ฟเวอร์ในเครือข่ายภายในของลูกค้าต่อเว็บในวงกว้างโดยไม่ได้ตั้งใจ
เว็บไซต์ที่เป็นอันตรายซึ่งส่งคำขอไปยังอุปกรณ์และเซิร์ฟเวอร์ที่โฮสต์บนเครือข่ายส่วนตัวนั้นถือเป็นภัยคุกคามมาอย่างยาวนาน เช่น ผู้โจมตีอาจเปลี่ยนแปลงการกำหนดค่าเราเตอร์ไร้สายเพื่อเปิดใช้การโจมตีแบบMan-in-the-Middle CORS-RFC1918 คือข้อเสนอให้บล็อกคำขอดังกล่าวโดยค่าเริ่มต้นบนเบราว์เซอร์ และกำหนดให้อุปกรณ์ภายในต้องเลือกรับคำขอจากอินเทอร์เน็ตสาธารณะ
เพื่อทำความเข้าใจว่าการเปลี่ยนแปลงนี้จะส่งผลต่อระบบนิเวศของเว็บอย่างไร ทีม Chrome จึงต้องการความคิดเห็นจากนักพัฒนาซอฟต์แวร์ที่สร้างเซิร์ฟเวอร์สำหรับเครือข่ายส่วนตัว
สถานภาพปัจจุบันไม่เหมาะสมอย่างไร
เว็บเซิร์ฟเวอร์จำนวนมากทำงานภายในเครือข่ายส่วนตัว เช่น เราเตอร์ไร้สาย เครื่องพิมพ์ เว็บไซต์อินทราเน็ต บริการขององค์กร และอุปกรณ์ Internet of Things (IoT) เป็นส่วนหนึ่งเท่านั้น เซิร์ฟเวอร์เหล่านี้อาจดูปลอดภัยมากกว่าที่เปิดเผยต่อสาธารณะ แต่ผู้โจมตีอาจละเมิดเซิร์ฟเวอร์ดังกล่าวโดยใช้หน้าเว็บเป็นพร็อกซีได้ ตัวอย่างเช่น เว็บไซต์ที่เป็นอันตรายสามารถฝัง URL ซึ่งเมื่อเหยื่อดูเพียงเท่านั้น (ในเบราว์เซอร์ที่เปิดใช้ JavaScript) จะพยายามเปลี่ยนการตั้งค่าเซิร์ฟเวอร์ DNS ในเราเตอร์บรอดแบนด์ในบ้านของเหยื่อ การโจมตีประเภทนี้เรียกว่า "Drive-By Pharming" และเกิดขึ้นในปี 2014 เราเตอร์ไร้สายที่มีช่องโหว่กว่า 300,000 เครื่องถูกแสวงหาประโยชน์จากการเปลี่ยนแปลงการตั้งค่า DNS และทำให้ผู้โจมตีสามารถเปลี่ยนเส้นทางผู้ใช้ไปยังเซิร์ฟเวอร์ที่เป็นอันตราย
CORS-RFC1918
ชุมชนเว็บได้ใช้ CORS-RFC1918 ซึ่งเป็นการแชร์ทรัพยากรข้ามต้นทาง (CORS) เฉพาะสำหรับเครือข่ายส่วนตัวที่กำหนดไว้ใน RFC1918 เพื่อลดภัยคุกคามจากการโจมตีที่คล้ายกัน
เบราว์เซอร์ที่ใช้ CORS จะตรวจสอบกับทรัพยากรเป้าหมายว่าโหลดจากต้นทางอื่นได้หรือไม่ ซึ่งจะมาพร้อมกับส่วนหัวเพิ่มเติมในบรรทัดที่อธิบายถึงการเข้าถึงหรือโดยการใช้กลไกที่เรียกว่าคำขอการตรวจสอบล่วงหน้า ทั้งนี้ขึ้นอยู่กับความซับซ้อน อ่านการแชร์ทรัพยากรข้ามต้นทางเพื่อดูข้อมูลเพิ่มเติม
เมื่อใช้ CORS-RFC1918 เบราว์เซอร์จะบล็อกการโหลดทรัพยากรผ่านเครือข่ายส่วนตัวโดยค่าเริ่มต้น ยกเว้นทรัพยากรที่เซิร์ฟเวอร์อนุญาตอย่างชัดเจนโดยใช้ CORS และผ่าน HTTPS เว็บไซต์ที่ส่งคำขอไปยังทรัพยากรเหล่านั้นจะต้องส่งส่วนหัว CORS และเซิร์ฟเวอร์จะต้องระบุไว้อย่างชัดเจนว่ายอมรับคำขอแบบข้ามต้นทางด้วยการตอบกลับด้วยส่วนหัว CORS ที่สอดคล้องกัน (ส่วนหัว CORS ที่แน่นอนยังอยู่ระหว่างการพัฒนา)
ระบบจะขอให้นักพัฒนาแอปของอุปกรณ์หรือเซิร์ฟเวอร์ดังกล่าวดำเนินการ 2 สิ่งต่อไปนี้
- ตรวจสอบว่าเว็บไซต์ที่ส่งคำขอไปยังเครือข่ายส่วนตัวนั้นแสดงผ่าน HTTPS
- ตั้งค่าการสนับสนุนเซิร์ฟเวอร์สำหรับ CORS-RFC1918 และตอบกลับด้วยส่วนหัว HTTP ที่คาดไว้
คำขอประเภทใดบ้างที่ได้รับผลกระทบ
คำขอที่ได้รับผลกระทบมีดังนี้
- คำขอจากเครือข่ายสาธารณะไปยังเครือข่ายส่วนตัว
- คำขอจากเครือข่ายส่วนตัวไปยังเครือข่ายภายใน
- คำขอจากเครือข่ายสาธารณะไปยังเครือข่ายภายใน
เครือข่ายส่วนตัว
ปลายทางที่แก้ไขเป็นพื้นที่ที่อยู่ส่วนตัวที่กำหนดไว้ในส่วนที่ 3 ของ RFC1918 ใน IPv4 ซึ่งเป็นที่อยู่ IPv6 ที่แมปกับ IPv4 โดยที่ที่อยู่ IPv4 ที่แมปไว้เป็นแบบส่วนตัว หรือที่อยู่ IPv6 นอกซับเน็ต ::1/128
, 2000::/3
และ ff00::/8
เครือข่ายภายใน
ปลายทางที่แปลค่าเป็นพื้นที่ "loopback" (127.0.0.0/8
) ที่กำหนดไว้ในส่วน 3.2.1.3 ของ RFC1122 ของ IPv4, พื้นที่ "link-local" (169.254.0.0/16
) ที่กำหนดไว้ใน
RFC3927 ของ IPv4, คำนำหน้า "Unique Local
Address" (fc00::/7
) ที่กําหนดไว้ในส่วน 3 ของ
RFC4193fe80::/10
RFC4291
เครือข่ายสาธารณะ เครือข่ายอื่นๆ ทั้งหมด
แผนของ Chrome ในการเปิดใช้ CORS-RFC1918
Chrome จะนำ CORS-RFC1918 มาใช้ใน 2 ขั้นตอน ดังนี้
ขั้นตอนที่ 1: คำขอที่ส่งไปยังทรัพยากรเครือข่ายส่วนตัวจะได้รับอนุญาตจากหน้าเว็บ HTTPS เท่านั้น
Chrome 87 เพิ่ม Flag ที่กำหนดให้เว็บไซต์สาธารณะส่งคำขอไปยังทรัพยากรเครือข่ายส่วนตัวเพื่อให้ใช้งาน HTTPS ได้ คุณสามารถไปที่
about://flags#block-insecure-private-network-requests
เพื่อเปิดใช้ เมื่อเปิดใช้แฟล็กนี้ คำขอทั้งหมดที่ส่งไปยังทรัพยากรเครือข่ายส่วนตัวจากเว็บไซต์ HTTP จะถูกบล็อก
ตั้งแต่ Chrome 88 เป็นต้นไป ระบบจะรายงานข้อผิดพลาด CORS-RFC1918 เป็นข้อผิดพลาดด้านนโยบาย CORS ในคอนโซล
ในแผงเครือข่ายของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome คุณสามารถเปิดใช้ช่องทำเครื่องหมายคำขอที่ถูกบล็อกเพื่อมุ่งเน้นไปที่คำขอที่ถูกบล็อก วิธีการมีดังนี้
ใน Chrome 87 ระบบจะรายงานข้อผิดพลาด CORS-RFC1918 เฉพาะในคอนโซลเครื่องมือสำหรับนักพัฒนาเว็บเป็น ERR_INSECURE_PRIVATE_NETWORK_REQUEST
แทน
คุณสามารถลองใช้งานด้วยตัวเองได้โดยใช้เว็บไซต์ทดสอบนี้
ขั้นตอนที่ 2: การส่งคำขอการตรวจสอบล่วงหน้าที่มีส่วนหัวพิเศษ
ในอนาคต เมื่อเว็บไซต์สาธารณะพยายามดึงข้อมูลทรัพยากรจากเครือข่ายส่วนตัวหรือเครือข่ายท้องถิ่น Chrome จะส่งคำขอการตรวจสอบล่วงหน้าก่อนคำขอจริง
คำขอจะมีส่วนหัว Access-Control-Request-Private-Network: true
นอกเหนือจากส่วนหัวของคำขออื่นๆ สำหรับ CORS ส่วนหัวเหล่านี้ยังช่วยระบุที่มาของคำขอได้อีกด้วย ช่วยให้ควบคุมการเข้าถึงแบบละเอียดได้ เซิร์ฟเวอร์จะตอบกลับด้วยส่วนหัว Access-Control-Allow-Private-Network:
true
เพื่อระบุอย่างชัดเจนว่าให้สิทธิ์การเข้าถึงทรัพยากร
ต้องการความคิดเห็น
หากคุณโฮสต์เว็บไซต์ภายในเครือข่ายส่วนตัวที่คาดว่าจะได้รับคำขอจากเครือข่ายสาธารณะ ทีม Chrome จะสนใจความคิดเห็นและกรณีการใช้งานของคุณ คุณมี 2 สิ่งที่คุณทำได้เพื่อช่วยเหลือ ได้แก่
- ไปที่
about://flags#block-insecure-private-network-requests
เปิดใช้ Flag และดูว่าเว็บไซต์ส่งคำขอไปยังทรัพยากรเครือข่ายส่วนตัวตามที่คาดไว้หรือไม่ - หากพบปัญหาหรือมีความคิดเห็น โปรดแจ้งปัญหาที่ crbug.com และตั้งคอมโพเนนต์เป็น
Blink>SecurityFeature>CORS>RFC1918
ตัวอย่างความคิดเห็น
เราเตอร์ไร้สายของเราให้บริการเว็บไซต์ผู้ดูแลระบบสำหรับเครือข่ายส่วนตัวเดียวกัน แต่ใช้ผ่าน HTTP หากต้องใช้ HTTPS สำหรับเว็บไซต์ที่ฝังเว็บไซต์ผู้ดูแลระบบ เว็บไซต์ดังกล่าวจะเป็นเนื้อหาผสม เราควรเปิดใช้ HTTPS ในเว็บไซต์ผู้ดูแลระบบในเครือข่ายแบบปิดไหม
นี่เป็นความคิดเห็นประเภทที่ Chrome ต้องการ โปรดแจ้งปัญหาเกี่ยวกับกรณีการใช้งานที่เป็นรูปธรรมได้ที่ crbug.com Chrome ยินดีรับฟังความคิดเห็นจากคุณ