Chrome 124 มีสิทธิ์เข้าถึงเครือข่ายส่วนตัวเพื่อผ่อนคลายฟีเจอร์เนื้อหาผสม ขณะนี้มีช่วงทดลองการเลิกใช้งานสำหรับเว็บไซต์ที่ต้องการเวลาเพิ่มเติมในการเตรียมพร้อมสำหรับการเปลี่ยนแปลงนี้ แต่ช่วงทดลองนี้จะสิ้นสุดลงเมื่อ Chrome 132 เปิดตัว ซึ่งคาดว่าจะเป็นวันที่ 4 กุมภาพันธ์ 2025 โพสต์นี้จะอธิบายการเปลี่ยนแปลง ข้อมูลเพิ่มเติมเกี่ยวกับการออกแบบฟีเจอร์ วิธีย้ายข้อมูลเว็บไซต์ปัจจุบัน และวิธีทดสอบการใช้งาน
สิ่งที่เปลี่ยนแปลง
หากต้องการสร้างการเชื่อมต่อกับอุปกรณ์ในเครือข่ายส่วนตัวที่ไม่มีชื่อที่ไม่ซ้ำกันทั่วโลก จึงไม่สามารถรับใบรับรอง TLS ฟีเจอร์นี้จะแนะนำตัวเลือกใหม่ใน fetch() เพื่อประกาศความตั้งใจของนักพัฒนาแอปที่จะสื่อสารกับอุปกรณ์ดังกล่าว ซึ่งรวมถึงฟีเจอร์ใหม่ที่ควบคุมโดยนโยบายเพื่อจำกัดการเข้าถึงความสามารถนี้ของเว็บไซต์แต่ละแห่ง และส่วนหัวใหม่สำหรับการตอบกลับก่อนเข้าสู่เซสชันของเซิร์ฟเวอร์เพื่อระบุข้อมูลเมตาเพิ่มเติม
การเข้าถึงเครือข่ายส่วนตัวคืออะไร
การเข้าถึงเครือข่ายส่วนตัว (PNA) ซึ่งก่อนหน้านี้เรียกว่า CORS-RFC1918 และเรียกสั้นๆ ว่าการเข้าถึงเครือข่ายภายใน) เป็นฟีเจอร์ความปลอดภัยที่จำกัดความสามารถของเว็บไซต์ในการส่งคำขอไปยังเซิร์ฟเวอร์ในเครือข่ายส่วนตัว ซึ่งจะช่วยปกป้องผู้ใช้และเครือข่ายภายในจากการโจมตีที่อาจเกิดขึ้น เช่น การปลอมแปลงคำขอข้ามเว็บไซต์ (CSRF) Chrome ค่อยๆ ใช้งาน PNA และเราจะขยายการปกป้องในรุ่นที่กำลังจะเปิดตัว
เหตุใดจึงต้องมีข้อความแจ้งสิทธิ์
Chrome 94 ได้เปิดตัวการบล็อกการเข้าถึงเครือข่ายส่วนตัวจากเว็บไซต์สาธารณะที่ไม่ปลอดภัย การทดลอง การเลิกใช้งานการเข้าถึงเครือข่ายส่วนตัวจากบริบทที่ไม่ปลอดภัยอย่างต่อเนื่องได้แสดงให้เห็นถึงความท้าทายในการย้ายข้อมูลเว็บไซต์ที่ได้รับผลกระทบไปยัง HTTPS ข้อกังวลที่พบบ่อยคือความยากในการย้ายข้อมูลอุปกรณ์ส่วนตัวไปยัง HTTPS ซึ่งนำไปสู่การละเมิดการตรวจสอบเนื้อหาแบบผสม
เพื่อรับมือกับความท้าทายนี้ เราได้เพิ่มข้อความแจ้งสิทธิ์ใหม่ภายใต้ช่วงทดลองใช้จากต้นทางจาก Chrome 120 และใน Chrome 124 เวอร์ชันเสถียร
เมื่อใดที่ต้องมีข้อความแจ้งสิทธิ์
เราวางแผนที่จะสิ้นสุดการทดลองเลิกใช้งานบริบทที่ไม่ปลอดภัยเมื่อถึงช่วงสำคัญของการเปิดตัวฟีเจอร์ข้อความแจ้งสิทธิ์ คุณต้องย้ายข้อมูลเว็บไซต์สาธารณะไปใช้ HTTPS เพื่อให้เข้ากันได้ หากย้ายเซิร์ฟเวอร์ส่วนตัวไปใช้ HTTPS ไม่ได้ ฟีเจอร์ข้อความแจ้งสิทธิ์ใหม่จะช่วยให้คุณผ่อนคลายการตรวจสอบเนื้อหาผสมได้
เวิร์กโฟลว์ทั่วไปสำหรับคำขอการเข้าถึงเครือข่ายส่วนตัวพร้อมข้อความแจ้งสิทธิ์มีดังนี้
เรียกใช้ข้อความแจ้งเกี่ยวกับสิทธิ์
เพิ่มแอตทริบิวต์ targetAddressSpace ใหม่เป็นตัวเลือกการดึงข้อมูล จากนั้นคําขอจะข้ามการตรวจสอบเนื้อหาแบบผสมได้
fetch("http://router.local/ping", {
targetAddressSpace: "private",
});
ตามการเข้าถึงเครือข่ายส่วนตัว: แนะนําการทดสอบก่อนเที่ยวบิน คําขอเครือข่ายส่วนตัวใดๆ ก็ตามจะมีคําขอทดสอบก่อนเที่ยวบินนำหน้า คําขอการตรวจสอบล่วงหน้านี้จะมีส่วนหัวใหม่ Access-Control-Request-Private-Network: true และการตอบกลับที่เกี่ยวข้องต้องมีส่วนหัว Access-Control-Allow-Private-Network: true
อุปกรณ์ต้องรวมส่วนหัวการตอบกลับใหม่ 2 รายการ ได้แก่ Private-Network-Access-Name และ Private-Network-Access-ID เพื่อให้รองรับข้อความแจ้งสิทธิ์ใหม่
Private-Network-Access-ID: ค่า 48 บิตที่แสดงเป็นไบต์ฐานสิบหก 6 ไบต์ โดยคั่นด้วยโคลอนPrivate-Network-Access-Name: ชื่อที่ถูกต้องเป็นสตริงที่ตรงกับนิพจน์ทั่วไปของ ECMAScript/^[a-z0-9_-.]+$/.ความยาวสูงสุดของชื่อคือหน่วยโค้ด UTF-8 จำนวน 248 หน่วย
Private-Network-Access-Name: "My Smart Toothbrush"
Private-Network-Access-ID: "01:23:45:67:89:0A"
สาธิต
คุณสามารถดูเดโมได้ที่ https://private-network-access-permission-test.glitch.me/
คุณต้องเริ่มเซิร์ฟเวอร์ส่วนตัวของคุณเองเพื่อใช้เว็บไซต์เดโม เซิร์ฟเวอร์ส่วนตัวควรตอบกลับด้วยส่วนหัว HTTP Access-Control-Allow-Private-Network: true พร้อมกับส่วนหัว Private-Network-Access-ID และ Private-Network-Access-Name ที่ระบุโดยเซิร์ฟเวอร์ หากตั้งค่าทุกอย่างถูกต้องแล้ว ระบบจะแสดงข้อความแจ้งสิทธิ์ต่อไปนี้
ออกจากช่วงทดลองใช้การเลิกใช้งานบริบทที่ไม่ปลอดภัย
สําหรับเว็บไซต์ที่ลงทะเบียนช่วงทดลองใช้การเลิกใช้งานการเข้าถึงเครือข่ายส่วนตัวสําหรับบริบทที่ไม่ปลอดภัย ตอนนี้เป็นเวลาที่คุณต้องย้ายข้อมูลเว็บไซต์ด้วยข้อความแจ้งสิทธิ์แบบใหม่ของเราและออกจากช่วงทดลองใช้
หลังจากอัปเดตโค้ดแล้ว ให้ลบโทเค็นการทดลองใช้ในส่วนหัว HTML, JavaScript หรือ HTTP หากจำไม่ได้ว่าคุณวางโทเค็นช่วงทดลองใช้ไว้ที่ใด โปรดดูส่วนลงทะเบียนช่วงทดลองใช้การเลิกใช้งานในบล็อกโพสต์ก่อนหน้า
นอกจากนี้ คุณอาจต้องลบโทเค็นในหน้าทดลองใช้ด้วย
ขั้นตอนถัดไปคือ
โซลูชันสำหรับคำขอจาก fetch() ที่ไม่ใช่ API ยังอยู่ระหว่างการสำรวจ
เราได้ทดสอบโซลูชันหลายอย่างแล้ว เช่น การใช้ Service Worker หรือการทำ Address Space เป้าหมายเป็น Content-Security-Policy ใหม่ แต่รูปแบบสุดท้ายของคำขอจาก fetch() ที่ไม่ใช่ API ยังอยู่ระหว่างการตรวจสอบ
นโยบายสิทธิ์อาจรองรับคำขอจากเฟรมย่อยในอนาคต
ในอนาคต เราอาจต้องการรองรับนโยบายสิทธิ์เพื่อผ่อนปรนการใช้เฟรมย่อย
ความคิดเห็นสำหรับกรณีการใช้งานเครือข่ายส่วนตัว
หากคุณโฮสต์เว็บไซต์ในเครือข่ายส่วนตัวที่ต้องใช้คำขอจากเครือข่ายสาธารณะ ทีม Chrome ต้องการความคิดเห็นจากคุณ แจ้งปัญหาที่เครื่องมือติดตามปัญหาของ Chromium (คอมโพเนนต์: Blink>SecurityFeature>CORS>PrivateNetworkAccess) หรือที่ที่เก็บของ GitHub