ลดความเสี่ยงที่เกี่ยวข้องกับการเปิดเผยอุปกรณ์และเซิร์ฟเวอร์ในเครือข่ายภายในของลูกค้าต่อเว็บในวงกว้างโดยไม่ตั้งใจ
เว็บไซต์ที่เป็นอันตรายซึ่งส่งคำขอไปยังอุปกรณ์และเซิร์ฟเวอร์ที่โฮสต์ในเครือข่ายส่วนตัว เป็นภัยคุกคามมานานแล้ว ตัวอย่างเช่น ผู้โจมตีอาจเปลี่ยนการกำหนดค่าของเราเตอร์ไร้สายเพื่อเปิดใช้การโจมตีแบบMan-in-the-Middle CORS-RFC1918 เป็นข้อเสนอในการบล็อกคำขอดังกล่าวโดยค่าเริ่มต้นใน เบราว์เซอร์ และกำหนดให้อุปกรณ์ภายในเลือกรับคำขอจากอินเทอร์เน็ตสาธารณะ
ทีม Chrome กำลังมองหาความคิดเห็นจากนักพัฒนาซอฟต์แวร์ที่สร้างเซิร์ฟเวอร์สำหรับเครือข่ายส่วนตัวเพื่อทำความเข้าใจว่าการเปลี่ยนแปลงนี้ส่งผลต่อระบบนิเวศของเว็บอย่างไร
สถานการณ์ปัจจุบันมีปัญหาอย่างไร
เว็บเซิร์ฟเวอร์จำนวนมากทำงานภายในเครือข่ายส่วนตัว ซึ่งรวมถึงเราเตอร์ไร้สาย เครื่องพิมพ์ เว็บไซต์อินทราเน็ต บริการระดับองค์กร และอุปกรณ์อินเทอร์เน็ตของสรรพสิ่ง (IoT) แม้ว่าเซิร์ฟเวอร์เหล่านั้นอาจดูเหมือนอยู่ในสภาพแวดล้อมที่ปลอดภัยกว่าเซิร์ฟเวอร์ที่เปิดให้บุคคลทั่วไปเข้าถึง แต่ผู้โจมตีก็สามารถใช้เซิร์ฟเวอร์เหล่านั้นในทางที่ผิดได้โดยใช้หน้าเว็บเป็นพร็อกซี ตัวอย่างเช่น เว็บไซต์ที่เป็นอันตรายสามารถฝัง URL ที่เมื่อเหยื่อดู (ในเบราว์เซอร์ที่เปิดใช้ JavaScript) ก็จะพยายามเปลี่ยนการตั้งค่าเซิร์ฟเวอร์ DNS ในเราเตอร์บรอดแบนด์ในบ้านของเหยื่อ การโจมตีประเภทนี้เรียกว่า "Pharming แบบ Drive-By" และเกิดขึ้นในปี 2014 เราเตอร์ไร้สายที่มีช่องโหว่กว่า 300,000 เครื่องถูกโจมตีโดยการเปลี่ยนการตั้งค่า DNS และอนุญาตให้ผู้โจมตีเปลี่ยนเส้นทางผู้ใช้ไปยังเซิร์ฟเวอร์ที่เป็นอันตราย
CORS-RFC1918
ชุมชนเว็บจึงนำCORS-RFC1918 ซึ่งเป็นการแชร์ทรัพยากรข้ามโดเมน (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
เครือข่ายในพื้นที่
ปลายทางที่เปลี่ยนเป็นพื้นที่ "ลูปแบ็ก" (127.0.0.0/8) ที่กำหนดไว้ใน
ส่วนที่ 3.2.1.3 ของ RFC1122 ของ IPv4, พื้นที่ "ลิงก์เฉพาะ" (169.254.0.0/16) ที่กำหนดไว้ใน
RFC3927 ของ IPv4, คำนำหน้า "ที่อยู่เฉพาะในพื้นที่" (fc00::/7) ที่กำหนดไว้ในส่วนที่ 3 ของ
RFC4193 ของ IPv6 หรือคำนำหน้า "ลิงก์เฉพาะ" (fe80::/10) ที่กำหนดไว้ในส่วนที่ 2.5.6 ของ
RFC4291 ของ IPv6
เครือข่ายสาธารณะ คนอื่นๆ ทั้งหมด
แผนของ Chrome ในการเปิดใช้ CORS-RFC1918
Chrome จะนำ CORS-RFC1918 มาใช้ใน 2 ขั้นตอน ดังนี้
ขั้นตอนที่ 1: อนุญาตคำขอไปยังทรัพยากรเครือข่ายส่วนตัวจากหน้าเว็บ HTTPS เท่านั้น
Chrome 87 เพิ่มฟีเจอร์ที่กำหนดให้เว็บไซต์สาธารณะที่ส่งคำขอไปยังแหล่งข้อมูลในเครือข่ายส่วนตัวต้องใช้ HTTPS
คุณไปที่
about://flags#block-insecure-private-network-requests เพื่อเปิดใช้ได้ เมื่อเปิดใช้ฟีเจอร์นี้ ระบบจะบล็อกคำขอไปยังทรัพยากรเครือข่ายส่วนตัวจากเว็บไซต์ HTTP
ตั้งแต่ Chrome 88 เป็นต้นไป ระบบจะรายงานข้อผิดพลาด CORS-RFC1918 เป็นข้อผิดพลาดเกี่ยวกับนโยบาย CORS ในคอนโซล
ในแผงเครือข่ายของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome คุณสามารถเลือกช่องทำเครื่องหมายคำขอที่ถูกบล็อก เพื่อโฟกัสที่คำขอที่ถูกบล็อกได้
ใน Chrome 87 ข้อผิดพลาด CORS-RFC1918 จะรายงานในคอนโซล DevTools เป็น
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 ยินดีรับฟังความคิดเห็นจากคุณ