เครื่องมือสำหรับนักพัฒนา · ตัวสร้าง UUID
เหตุใด crypto.randomUUID() จึงล้มเหลวบน HTTP หน้า: อธิบายบริบทที่ปลอดภัย
· มันทำงานอย่างไร
uuid การเข้ารหัส เบราว์เซอร์-apis
crypto.randomUUID ทำงานบน localhost และบน HTTPS จากนั้นหายไปบนโฮสต์ธรรมดา-HTTP staging โพสต์นี้จะอธิบายกฎบริบทที่ปลอดภัยที่อยู่เบื้องหลังพฤติกรรมดังกล่าว และวิธีการสร้าง UUID อย่างปลอดภัยเมื่อนำไปใช้
TypeError ในการแสดงละคร ใช้ได้ในทุกที่ — อาการและความแตกต่างของสภาพแวดล้อมที่เป็นสาเหตุ
นักพัฒนาตรวจสอบงานของตนบน localhost:3000 และตัวสร้าง UUID ก็ทำงานได้อย่างสมบูรณ์ พวกเขาปรับใช้กับการจัดเตรียมที่ http://staging. ภายใน ตัวอย่าง. com (ธรรมดา HTTP บนบริษัท LAN) และโค้ดส่ง TypeError: crypto.randomUUID ไม่ใช่ฟังก์ชัน รหัสเดียวกันในการผลิตบน https://example. com ทำงานได้ดี ความไม่สอดคล้องกันนั้นน่าสับสนจนกว่าพวกเขาจะอ่านเอกสาร MDN: crypto.randomUUID ถูกจำกัดไว้เฉพาะบริบทที่ปลอดภัย บริบทที่ปลอดภัยคือ HTTPS หรือ localhost ต้นกำเนิดธรรมดา HTTP บน LAN ไม่ปลอดภัยตามกฎของเบราว์เซอร์ แม้ว่าเครือข่ายจะเป็นส่วนตัวก็ตาม การแก้ไขคือการใช้ crypto.getRandomValues กับการดำเนินการบิตแบบแมนนวล หรือเพื่ออัพเกรดเซิร์ฟเวอร์ staging เป็น HTTPS กฎบริบทที่ปลอดภัยถูกนำมาใช้เพื่อป้องกันไม่ให้ API ที่มีความละเอียดอ่อนรั่วไหลไปยังการเชื่อมต่อที่ไม่ได้เข้ารหัส
บริบทที่ปลอดภัยคืออะไร — กฎของเบราว์เซอร์ที่สงวน API บางอย่างสำหรับ HTTPS ต้นกำเนิดและสำหรับ localhost
เพจบน HTTP ธรรมดาสามารถถูกดักจับโดยผู้โจมตีเครือข่าย การเปิดเผย API การเข้ารหัสไปยังหน้าดังกล่าวจะทำให้ผู้โจมตีสามารถสร้างตัวระบุโดยใช้ API ที่ถูกบุกรุกได้ HTTPS เข้ารหัสเพจและการสื่อสาร API ทั้งหมด เพื่อให้ผู้โจมตีบนเครือข่ายไม่สามารถสกัดกั้นหรือแก้ไขโค้ดได้ Localhost ได้รับการปฏิบัติว่ามีความปลอดภัยโดยเนื้อแท้เนื่องจากมีอยู่ในเครื่องท้องถิ่นเท่านั้นและไม่สามารถดักจับผ่านเครือข่ายได้ ต้นกำเนิด HTTP อื่นๆ (ที่อยู่ LAN ซึ่งเป็นโดเมนสาธารณะที่ไม่มี HTTPS พร็อกซีย้อนกลับที่ส่งต่อไปยัง HTTP) ไม่ปลอดภัยตามคำจำกัดความ Web Crypto API แบ่งออกเป็นสองฟังก์ชัน: crypto.randomUUID จำกัดเฉพาะบริบทที่ปลอดภัย และ crypto.getRandomValues พร้อมใช้งานทั้งในบริบทที่ปลอดภัยและไม่ปลอดภัย ทั้งสองใช้ระบบปฏิบัติการเดียวกัน CSPRNG
ส่วนใดของ Web Crypto ที่ถูกควบคุม - crypto.randomUUID และ crypto.subtle ต้องการบริบทที่ปลอดภัย ในขณะที่ crypto.getRandomValues ไม่
ความแตกต่างก็คือ getRandomValues ไม่ได้ซ่อนความจริงที่ว่าคุณกำลังใช้การเข้ารหัส เพจที่ใช้จะต้องร้องขอไบต์แบบสุ่มอย่างชัดเจน ฟังก์ชัน RandomUUID คือความสะดวกที่บังคับใช้บริบทที่ปลอดภัยด้วย หากแอปพลิเคชันของคุณจำเป็นต้องสร้าง UUID บนเพจที่ไม่ปลอดภัย คุณต้องใช้ getRandomValues และตั้งค่าเวอร์ชันและบิตตัวแปรด้วยตนเอง RFC 9562 ระบุการดำเนินการบิต: ตั้งค่าไบต์ 6 เป็น (byte6 & 0x0f) | 0x40 สำหรับเวอร์ชัน 4 และไบต์ 8 ถึง (byte8 & 0x3f) | 0x80 สำหรับตัวแปร RFC ไลบรารี ToolAcre ทำสิ่งนี้เป็นทางเลือกเมื่อ RandomUUID ไม่พร้อมใช้งาน การสร้างความล้มเหลวขึ้นมาใหม่: ให้บริการเพจธรรมดาจากต้นทาง HTTP ธรรมดาที่ไม่ถือว่าน่าเชื่อถือ ตรวจสอบว่ามีการเปิดเผย RandomUUID หรือไม่ จากนั้นเปรียบเทียบ getRandomValues ซึ่งการอ้างอิง Web Crypto อนุญาตในบริบทที่ไม่ปลอดภัย
การสร้าง v4 UUID จาก getRandomValues — การมาสก์และฟอร์แมตทางเลือกสำรองที่ทำให้คุณอยู่ใน CSPRNG เมื่อ RandomUUID หายไป
รหัสเดียวกันในไฟล์ที่ให้บริการบน HTTPS สามารถเปิดเผย RandomUUID ได้ หากการผลิตรายงาน "randomUUID ไม่ใช่ฟังก์ชัน" ให้ตรวจสอบก่อนว่าต้นทางเป็นบริบทที่ปลอดภัยหรือไม่ จากนั้นตรวจสอบการสนับสนุนเบราว์เซอร์และสคริปต์อื่นแทนที่ออบเจ็กต์ crypto หรือไม่ วิธีแก้ไขอาจเป็น HTTPS หรือการใช้งาน getRandomValues ที่ตั้งค่าบิต UUID อย่างชัดเจน Math.random polyfill ไม่ใช่ทางเลือกสำรองที่เทียบเท่า: สร้างรูปร่างใหม่ในขณะที่ยกเลิกสัญญาแหล่งที่มาของการเข้ารหัส การทดสอบที่ยืนยันเฉพาะขีดกลางและตัวเลขเวอร์ชันจะพลาดการทดแทน ดังนั้นให้ตรวจสอบเส้นทางแหล่งที่มาตลอดจนสตริงผลลัพธ์
ตัวอย่างการทำงาน — การสร้างความล้มเหลวบนต้นทาง http:// และยืนยันการแก้ไข
แต่ตอนนี้ตัวระบุสามารถคาดเดาได้ ผู้โจมตีที่จับ UUID บางส่วนจากระบบของคุณสามารถคาดเดาอันถัดไปได้ หากแอปพลิเคชันถือว่าตัวระบุดังกล่าวเป็นข้อมูลประจำตัวของผู้ถือโดยไม่ได้ตั้งใจ ความสามารถในการคาดเดาได้จะกลายเป็นความล้มเหลวในการอนุญาตแทนที่จะเป็นข้อบกพร่องเชิงความสวยงาม กลยุทธ์ที่ถูกต้องคืออัปเกรดเซิร์ฟเวอร์เป็น HTTPS (ย้ายอย่างถูกต้องเสมอสำหรับเพจใดๆ ที่มีการตรวจสอบสิทธิ์หรือข้อมูลที่ละเอียดอ่อน) หรือใช้ getRandomValues กับการดำเนินการบิตที่ชัดเจน (ซึ่งใช้โค้ดมากกว่าแต่มีเสียงที่เข้ารหัส) เบราว์เซอร์บังคับใช้บริบทที่ปลอดภัย คุณไม่สามารถหลีกเลี่ยงได้ด้วยการกำหนดค่าหรือตัวแปรสภาพแวดล้อม ตัวสร้าง ToolAcre ถูกใช้งานบน HTTPS ดังนั้น crypto.randomUUID จึงพร้อมใช้งาน เมื่อคุณสร้าง UUID ในเครื่องมือ เครื่องมือจะใช้ RandomUUID (หากการตรวจสอบบริบทที่ปลอดภัยผ่าน) หรือ getRandomValues ด้วยการดำเนินการบิต (หากคุณใช้ HTTP ธรรมดา แม้ว่าจะพบได้ยากก็ตาม)
เหตุใดคุณจึงไม่ควรเติมโพลีฟิลด้วย Math.random — ทางลัดที่น่าดึงดูดและต้นทุนด้านความปลอดภัย
ไม่มีเส้นทางใดที่ย้อนกลับไปที่ Math.random หากคุณกำลังสร้างตัวสร้าง UUID ของคุณเองและกำหนดเป้าหมายไปยังต้นทางที่ไม่ปลอดภัย ให้ใช้ getRandomValues และดำเนินการบิตด้วยตนเอง ทดสอบทั้ง HTTPS และ localhost เพื่อยืนยันว่า RandomUUID ทำงาน จากนั้นทดสอบบนต้นทาง http:// เพื่อยืนยันว่าทางเลือก getRandomValues ของคุณถูกต้อง การทำความเข้าใจข้อจำกัดบริบทที่ปลอดภัยช่วยให้คุณออกแบบกลยุทธ์การปรับใช้ หากแอปพลิเคชันของคุณต้องทำงานบน LAN ส่วนตัวโดยไม่มี HTTPS (โครงสร้างพื้นฐานแบบเดิม ระบบฝังตัว) ทางเลือก getRandomValues คือเส้นทางข้างหน้าของคุณ หากคุณมีทางเลือก ให้อัปเกรดเป็น HTTPS ทุกที่ ใช้งานได้ฟรีกับ Let's Encrypt และการลงทุนจะคืนความปลอดภัยให้กับแอปพลิเคชันทั้งหมด การพัฒนาบน localhost นั้นไม่มีข้อจำกัด ดังนั้นให้ทดสอบตัวสร้าง UUID ของคุณบน localhost และบน HTTPS staging ก่อนที่จะปรับใช้กับการใช้งานจริง การผลิตควร HTTPS เสมอ
สิ่งนี้ไม่ครอบคลุม — รันไทม์ของเซิร์ฟเวอร์ เช่น Node.js และ Deno ซึ่งเปิดเผย API โดยไม่มีกฎบริบทที่ปลอดภัย
ข้อจำกัดนี้ไม่ใช่จุดบกพร่องหรือความรำคาญ เป็นคุณลักษณะด้านความปลอดภัยที่ป้องกันอุบัติเหตุและบังคับให้คุณคิดถึงการเข้ารหัส รูปแบบที่กว้างขึ้นคือ API การเข้ารหัสเว็บถูกควบคุมโดยบริบทที่ปลอดภัย crypto.getRandomValues การเข้ารหัสลับ บอบบาง เข้ารหัส, การเข้ารหัสลับ บอบบาง GenerateKey และการดำเนินการที่สำคัญอื่นๆ ทั้งหมดต้องใช้ HTTPS หรือ localhost ไม่มีข้อยกเว้น ไม่มีการแทนที่ และไม่มีทางที่จะปิดใช้งานการตรวจสอบได้ หน้าที่ไม่ปลอดภัยเพียงหน้าเดียวจะทำลายการรับประกันความปลอดภัยสำหรับผู้ใช้ของคุณ แม้ว่าคุณจะระมัดระวังในการใช้ API การเข้ารหัสลับเฉพาะในบางหน้า ข้อผิดพลาด (หรือการพึ่งพาที่มีตัวสร้าง UUID) อาจทำให้การสร้างแบบสุ่มรั่วไหลไปยังหน้าที่ไม่ได้เข้ารหัสได้ ตัวสร้าง ToolAcre บังคับใช้สิ่งนี้ในระดับโค้ด: หาก RandomUUID ไม่พร้อมใช้งาน (บริบทที่ไม่ปลอดภัย) ตัวสร้างจะใช้ getRandomValues ซึ่งพร้อมใช้งาน แต่แจ้งเตือนผู้ตรวจสอบโค้ดว่ามีบางอย่างผิดปกติเกิดขึ้น
ประเด็นสำคัญ: แก้ไขต้นทาง ไม่ใช่ตัวสร้าง — ToolAcre ให้บริการบน HTTPS ดังนั้นตัวสร้างจึงทำงานในบริบทที่ปลอดภัยโดยการออกแบบ
ยังดีกว่านั้น ระบบปฏิเสธที่จะสร้างตัวระบุหากบริบทที่ปลอดภัยไม่พร้อมใช้งานอย่างแท้จริง (ในสภาพแวดล้อมที่ไม่มี getRandomValues เช่นกัน ซึ่งพบได้ยาก แต่เป็นไปได้ในระบบเก่าหรือระบบฝังตัว) การย้ายระบบที่มีอยู่ไปยัง HTTPS เพื่อรองรับ API การเข้ารหัสที่ปลอดภัยถือเป็นโครงการทั่วไป เริ่มต้นด้วยต้นทางที่สร้าง UUID (เซิร์ฟเวอร์การตรวจสอบสิทธิ์ของคุณ แบ็กเอนด์ API หรือบริการแอปพลิเคชันคีย์) รับใบรับรอง TLS (Let's Encrypt มอบให้ฟรี) กำหนดค่าเว็บเซิร์ฟเวอร์ของคุณให้ให้บริการ HTTPS โดยค่าเริ่มต้น และเปลี่ยนเส้นทางคำขอ HTTP ไปยัง HTTPS ทดสอบกับหลายเบราว์เซอร์และไคลเอนต์ API เพื่อให้แน่ใจว่าทุกอย่างทำงานได้ จากนั้นตรวจสอบโค้ดของคุณสำหรับ crypto API ที่เหลืออยู่ซึ่งอาจถูกเรียกใช้บนเพจที่ไม่ได้เข้ารหัสและแก้ไข ตัวสร้าง ToolAcre ถือว่า HTTPS; หากคุณใช้มัน แสดงว่าคุณเป็นส่วนหนึ่งของเส้นทางนั้นแล้ว