ลดความเสี่ยงที่อาจเกิดขึ้นจากการเปิดเผยอุปกรณ์และเซิร์ฟเวอร์ในเครือข่ายภายในของลูกค้าต่อเว็บโดยไม่ได้ตั้งใจ
เว็บไซต์ที่เป็นอันตรายซึ่งส่งคำขอไปยังอุปกรณ์และเซิร์ฟเวอร์ที่โฮสต์ในเครือข่ายส่วนตัวถือเป็นภัยคุกคามมาอย่างยาวนาน ตัวอย่างเช่น ผู้โจมตีอาจเปลี่ยนการกำหนดค่าของเราเตอร์ไร้สายเพื่อเปิดใช้การโจมตีMan-in-the-Middle CORS-RFC1918 คือข้อเสนอในการบล็อกคําขอดังกล่าวโดยค่าเริ่มต้นในเบราว์เซอร์ และกำหนดให้อุปกรณ์ภายในต้องเลือกใช้คําขอจากอินเทอร์เน็ตสาธารณะ
ทีม Chrome ต้องการความคิดเห็นจากนักพัฒนาซอฟต์แวร์ที่สร้างเซิร์ฟเวอร์สำหรับเครือข่ายส่วนตัวเพื่อให้เข้าใจว่าการเปลี่ยนแปลงนี้ส่งผลต่อระบบนิเวศของเว็บอย่างไร
สถานะปัจจุบันมีปัญหาอะไร
เว็บเซิร์ฟเวอร์จำนวนมากทำงานภายในเครือข่ายส่วนตัว เช่น เราเตอร์ไร้สาย เครื่องพิมพ์ เว็บไซต์อินทราเน็ต บริการสำหรับองค์กร และอุปกรณ์อินเทอร์เน็ตของสรรพสิ่ง (IoT) ดูเหมือนว่าเซิร์ฟเวอร์เหล่านี้จะอยู่ในสภาพแวดล้อมที่ปลอดภัยกว่าเซิร์ฟเวอร์ที่เปิดเผยต่อสาธารณะ แต่ผู้โจมตีอาจใช้เว็บเพจเป็นพร็อกซีเพื่อละเมิดเซิร์ฟเวอร์เหล่านั้นได้ ตัวอย่างเช่น เว็บไซต์ที่เป็นอันตรายอาจฝัง URL ที่เมื่อเหยื่อดู (ในเบราว์เซอร์ที่เปิดใช้ JavaScript) ก็จะพยายามเปลี่ยนการตั้งค่าเซิร์ฟเวอร์ DNS ในเราเตอร์บรอดแบนด์ในบ้านของเหยื่อ การโจมตีประเภทนี้เรียกว่า "Drive-By Pharming" และเกิดขึ้นในปี 2014 มีการโจมตีเราเตอร์ไร้สายที่มีช่องโหว่กว่า 300,000 ตัวโดยเปลี่ยนการตั้งค่า DNS และอนุญาตให้ผู้โจมตีเปลี่ยนเส้นทางผู้ใช้ไปยังเซิร์ฟเวอร์ที่เป็นอันตราย
CORS-RFC1918
เพื่อลดภัยคุกคามจากโจมตีที่คล้ายกัน ชุมชนเว็บจึงนำ CORS-RFC1918 ซึ่งเป็น Cross Origin Resource Sharing (CORS) เฉพาะสำหรับเครือข่ายส่วนตัวที่ระบุไว้ใน RFC1918 มาใช้
เบราว์เซอร์ที่ใช้ CORS จะตรวจสอบกับทรัพยากรเป้าหมายว่าอนุญาตให้โหลดจากต้นทางอื่นได้หรือไม่ ซึ่งทำได้โดยใช้ส่วนหัวเพิ่มเติมในบรรทัดอธิบายการเข้าถึง หรือใช้กลไกที่เรียกว่าคําขอ Preflight ทั้งนี้ขึ้นอยู่กับความซับซ้อน อ่านข้อมูลเพิ่มเติมเกี่ยวกับกลไกการแชร์ทรัพยากรข้ามโดเมน
เมื่อใช้ 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 ของ RFC4193 ของ IPv6 หรือส่วนนำหน้า "link-local" (fe80::/10) ที่ระบุไว้ในส่วนที่ 2.5.6 ของ RFC4291 ของ IPv6
เครือข่ายสาธารณะ เครือข่ายอื่นๆ ทั้งหมด
แผนของ Chrome ในการเปิดใช้ CORS-RFC1918
Chrome จะเปิดตัว CORS-RFC1918 ใน 2 ขั้นตอน ดังนี้
ขั้นตอนที่ 1: ระบบจะอนุญาตคำขอทรัพยากรเครือข่ายส่วนตัวจากหน้าเว็บ HTTPS เท่านั้น
Chrome 87 เพิ่ม Flag ที่กําหนดให้เว็บไซต์สาธารณะที่ส่งคําขอไปยังแหล่งข้อมูลเครือข่ายส่วนตัวต้องใช้ HTTPS คุณสามารถไปที่ about://flags#block-insecure-private-network-requests เพื่อเปิดใช้ เมื่อเปิดใช้ Flag นี้ ระบบจะบล็อกคำขอทรัพยากรเครือข่ายส่วนตัวจากเว็บไซต์ 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แล้วเปิดการตั้งค่า แล้วดูว่าเว็บไซต์ส่งคำขอไปยังทรัพยากรเครือข่ายส่วนตัวตามที่คาดไว้หรือไม่ - หากพบปัญหาหรือมีความคิดเห็น โปรดรายงานปัญหาที่ crbug.com และตั้งค่าคอมโพเนนต์เป็น
Blink>SecurityFeature>CORS>RFC1918
ตัวอย่างความคิดเห็น
เราใช้เราเตอร์ไร้สายเพื่อแสดงเว็บไซต์ผู้ดูแลระบบสำหรับเครือข่ายส่วนตัวเดียวกัน แต่ผ่าน HTTP หากเว็บไซต์ที่ฝังเว็บไซต์ผู้ดูแลระบบต้องใช้ HTTPS เว็บไซต์ดังกล่าวจะเป็นเนื้อหาผสม เราควรเปิดใช้ HTTPS ในเว็บไซต์ผู้ดูแลระบบในเครือข่ายที่ปิดไหม
นี่เป็นความคิดเห็นที่ Chrome ต้องการ โปรดรายงานปัญหาพร้อม Use Case ที่ชัดเจนที่ crbug.com Chrome ยินดีรับฟังความคิดเห็นจากคุณ