วิกฤตความเชื่อมั่น JavaScript บนเว็บ: มาตรฐานความสมบูรณ์ใหม่จะช่วยกู้การเข้ารหัสแบบ end-to-end ได้หรือไม่?

คำนำโมเดลความปลอดภัยพื้นฐานของเว็บแอปพลิเคชันกำลังเผชิญกับความท้าทายที่สำคัญ: ผู้ใช้จะเชื่อมั่นได้อย่างไรว่าโค้ด JavaScript ที่ทำงานในเบราว์เซอร์ของพวกเขายังไม่ถูกแก้ไข? คำถามนี้มีความเร่งด่วนเป็นพิเศษสำหรับบริการส่งข้อความที่เข้ารหัสแบบ end-to-end และแอปพลิเคชันทางการเงินซึ่งความสมบูรณ์ของโค้ดเป็นสิ่งสำคัญที่สุด ในขณะที่แอปแบบ native ได้รับประโยชน์จากกลไกการลงลายเซ็นในร้านค้าแอป แต่เว็บแอปพลิเคชันในอดีตขาดการป้องกันที่เทียบเท่า ส่งผลให้เกิดสิ่งที่ผู้เชี่ยวชาญด้านความปลอดภัยเรียกว่าปัญหา JavaScript cryptography ข้อเสนอล่าสุดสำหรับมาตรฐานความสมบูรณ์ของเว็บแอปพลิเคชันกำลังก่อให้เกิดการอภิปรายอย่างเข้มข้นในหมู่ผู้พัฒนาและนักวิจัยด้านความปลอดภัยเกี่ยวกับว่าเราจะสามารถนำหลักประกันความปลอดภัยในระดับเดียวกับ native app สู่เว็บได้ในที่สุดหรือไม่

บล็อกโพสต์ที่พูดถึงความสำคัญของการปรับปรุงความปลอดภัยของ JavaScript บนเว็บ

ปัญหาหลักของความปลอดภัยเว็บแอปพลิเคชัน

ปัญหาพื้นฐานที่บ่อนทำลายความปลอดภัยของเว็บแอปพลิเคชันมาจากธรรมชาติแบบไดนามิกของการส่งมอบโค้ด ซึ่งแตกต่างจากแอปพลิเคชันมือถือแบบ native ที่มีการลงลายเซ็นด้วยการเข้ารหัสและกระจายผ่านร้านค้าแอป โดยเว็บแอปพลิเคชันจะถูกส่งมาใหม่ในทุกครั้งที่เข้าเยี่ยมชม สร้างเวกเตอร์การโจมตีหลายทาง เซิร์ฟเวอร์ที่ถูกบุกรุกสามารถส่งมอบโค้ดที่เป็นอันตรายไปยังผู้ใช้เฉพาะตามที่อยู่ IP ตำแหน่งทางภูมิศาสตร์ หรือแม้แต่คุกกี้ติดตาม ซึ่งเป็นการบ่อนทำลายรากฐานของการเข้ารหัสแบบ end-to-end เอง ดังที่ผู้แสดงความคิดเห็นหนึ่งคนระบุไว้:

ปัญหาแบบดั้งเดิมของการส่งข้อความแบบ E2EE บนเว็บก็คือ จุดประสงค์ของ E2EE คือคุณไม่จำเป็นต้องเชื่อใจเซิร์ฟเวอร์ว่าจะไม่อ่านข้อความของคุณ แต่ถ้าคุณใช้ไคลเอนต์เว็บ คุณต้องเชื่อใจเซิร์ฟเวอร์ที่จะส่ง JS ให้คุณ ซึ่งจะไม่ส่งเพียงข้อความธรรมดาของคุณไปยังผู้ดูแลระบบ

สิ่งนี้สร้างสถานการณ์ที่ขัดแย้งกัน โดยผู้ใช้ต้องเชื่อใจองค์กรเดียวกันกับที่พวกเขาพยายามปกป้องตัวเองจากปัญหาเหล่านี้ extends เกินกว่าความตั้งใจที่เป็นอันตราย — แม้แต่เซิร์ฟเวอร์ที่เชื่อถือได้แต่ถูกบุกรุกก็สามารถส่งโค้ดที่ถูกแก้ไขได้โดยไม่ตั้งใจ ซึ่งเป็นการ bypass การเข้ารหัสฝั่งไคลเอนต์โดยสมบูรณ์

ความท้าทายด้านความปลอดภัยหลักสำหรับเว็บแอปพลิเคชัน

การส่งมอบโค้ดแบบไดนามิกทำให้เกิดการโจมตีแบบกำหนดเป้าหมาย ไม่มีกลไกการลงนามที่เทียบเท่ากับแอปพลิเคชันแบบ native การถูกบุกรุกเซิร์ฟเวอร์ทำลายความปลอดภัยฝั่งไคลเอนต์อย่างสิ้นเชิง โซลูชันที่มีอยู่ให้การปกป้องเพียงบางส่วนเท่านั้น *ช่องว่างด้านความโปร่งใสและการตรวจสอบได้เมื่อเทียบกับแอปพลิเคชันแบบ native

ไดอะแกรมแสดง inclusion proof process และขั้นตอนการตรวจสอบยืนยันที่เกี่ยวข้องกับความปลอดภัยของเว็บแอปพลิเคชัน

โซลูชันที่มีอยู่และข้อจำกัด

ฟีเจอร์ความปลอดภัยบนเว็บในปัจจุบัน เช่น Subresource Integrity (SRI) ให้โซลูชันบางส่วนแต่ยังไม่ถึงขั้นการป้องกันที่ครอบคลุม SRI อนุญาตให้นักพัฒนาระบุแฮชการเข้ารหัสสำหรับทรัพยากรภายนอกเช่นสคริปต์และสไตล์ชีต ช่วยให้เบราว์เซอร์สามารถยืนยันความสมบูรณ์ก่อนการดำเนินการ อย่างไรก็ตาม SRI มีข้อจำกัดที่สำคัญ — ไม่ครอบคลุมเอกสาร HTML หลัก ต้องการการจัดการแฮชด้วยตนเอง และกลายเป็นสิ่งที่ใช้งานไม่ได้จริงสำหรับแอปพลิเคชันขนาดใหญ่ที่อัปเดตบ่อยครั้ง ผู้พัฒนาหนึ่งคนชี้ให้เห็นว่าถ้าเซิร์ฟเวอร์ของคุณถูกบุกรุก มันก็จบเกม แม้ว่าผู้เผยแพร่จะไม่มีความตั้งใจร้าย ก็เน้นย้ำว่า SRI ล้มเหลวในการแก้ไขสถานการณ์การบุกรุกเซิร์ฟเวอร์ระดับรากฐาน

การอภิปรายยังเปิดเผยความกังวลที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับโมเดลร้านค้าแอปที่มีอยู่ด้วย ดังที่ผู้แสดงความคิดเห็นหนึ่งคนสังเกตเกี่ยวกับ Google Play: แอปทั้งหมดที่สร้างตั้งแต่ปี 2021 ต้องใช้ Google Play App Signing ซึ่งหมายความว่า Google ถือกุญแจที่ใช้ในการลงลายเซ็นแอพ รูปแบบ Android App Bundle หมายความว่ามีการส่งเวอร์ชันแอปที่แตกต่างกันโดยสิ้นเชิงขึ้นอยู่กับประเภทของอุปกาย โลเคล ฯลฯ ซึ่งมีความโปร่งใสเป็น 0 สำหรับผู้ใช้ปลายทาง สิ่งนี้ชี้ให้เห็นว่าแม้แต่การกระจายแอป native ก็มีปัญหาความโปร่งใสที่ต้องได้รับการแก้ไข

การเปรียบเทียบโซลูชันความสมบูรณ์ของเว็บในปัจจุบัน

การแสดงภาพของแฮชเชนที่สาธิตความสัมพันธ์ระหว่างจุดข้อมูลในความปลอดภัยของเว็บแอปพลิเคชัน

การอภิปรายเรื่องความโปร่งใสและการลงลายเซ็นโค้ด

ความตึงเครียดหลักในการอภิปรายของชุมชนเกี่ยวข้องกับว่าบันทึกความโปร่งใส (transparency logs) หรือการลงลายเซ็นโค้ด (code signing) ควรเป็นรากฐานของความปลอดภัยเว็บแอปพลิเคชันหรือไม่ ผู้สนับสนุนความโปร่งใสแย้งว่าบันทึกที่สามารถตรวจสอบได้สาธารณะของการปรับใช้โค้ดทั้งหมดสร้างบันทึกที่ไม่สามารถย้อนกลับได้ซึ่งสามารถตรวจจับการบุกรุกได้ ในขณะที่ผู้สนับสนุนการลงลายเซ็นโค้ดเน้นยึงถึงความสำคัญของที่มาทางการเข้ารหัส (cryptographic provenance) ความเป็นจริงน่าจะต้องการทั้งสองแนวทางทำงานร่วมกัน

ความคิดเห็นทางเทคนิคหนึ่งเรื่องเน้นย้ำถึงการพึ่งพาอาศัยกัน: ความโปร่งใสเป็นสิ่งสำคัญ และการลงลายเซ็นโค้ดจำเป็นต้องสร้างขึ้นบนนั้น สมมติว่าคุณมีการลงลายเซ็นโค้ดแต่ไม่มีความโปร่งใส เว็บไซต์ของคุณมีวิธีบางอย่างในการส่งสัญญาณไปยังเบราว์เซอร์เพื่อตรวจสอบลายเซ็นโค้ดภายใต้ public key บางอัน สมมติตอนนี้ว่าเว็บไซต์ของคุณถูกบุกรุก อะไรที่จะป้องกันไม่ให้ผู้โจมตีเปลี่ยน public key และลงลายเซ็นใหม่ภายใต้ public key ใหม่? ข้อมูลเชิงลึกนี้เผยให้เห็นว่าความโปร่งใสให้รากฐานที่จำเป็นซึ่งทำให้การลงลายเซ็นโค้ดมีประสิทธิภาพต่อการบุกรุกเซิร์ฟเวอร์

ความท้าทายในการนำไปปฏิบัติจริง

นักพัฒนาได้หยิบยกข้อกังวลในทางปฏิบัติมากมายเกี่ยวกับการนำมาตรการความปลอดภัยเหล่านี้ไปใช้ ความซับซ้อนของการผนวกรวมเข้ากับกระบวนการ build ที่มีอยู่ ผลกระทบต่อประสิทธิภาพ และศักยภาพที่จะทำให้ฟังก์ชันการทำงานของเบราว์เซอร์ที่มีอยู่เสียหาย ถูกกล่าวถึงบ่อยครั้ง ผู้พัฒนาหนึ่งคนแสดงความสงสัยเกี่ยวกับแนวทางที่เสนอโดยอิง manifest: ฉันคงเกลียดที่จะต้องรวมสิ่งนี้เข้ากับกระบวนการ build ของฉัน ซึ่งชี้ให้เห็นว่าการยอมรับจะขึ้นอยู่กับประสบการณ์และเครื่องมือของนักพัฒนาเป็นอย่างมาก

การอภิปรายยัง касаетсяคำถามทางสถาปัตยกรรมที่พื้นฐานมากขึ้นอีกด้วย ดังที่ผู้แสดงความคิดเห็นหนึ่งคนระบุว่า: ทำไมต้องสร้างแผนที่ของแฮชที่สอดคล้องกับ url ไฟล์ที่มนุษย์อ่านได้ ในเมื่อเราสามารถลิงก์ไปยังแฮชโดยตรงได้? นี่อ้างอิงถึงระบบจัดเก็บข้อมูลที่อ้างอิงเนื้อหา (content-addressable storage) เช่น IPFS ชี้ให้เห็นว่าการเปลี่ยนแปลงทางสถาปัตยกรรมที่รุนแรงกว่าอาจให้โซลูชันระยะยาวที่ดีกว่าการเพิ่มการยืนยันความสมบูรณ์ลงบนโครงสร้างพื้นฐานเว็บที่มีอยู่

หนทางสู่ความปลอดภัยบนเว็บในอนาคต

ฉันทามติของชุมชนชี้ให้เห็นว่าไม่มีโซลูชันใดโซลูชันหนึ่งที่จะแก้ปัญหาความเชื่อมั่นบนเว็บได้อย่างเต็มที่ แต่จะต้องใช้การรวมกันของแนวทางต่างๆ บันทึกความโปร่งใส การลงลายเซ็นโค้ด การจัดเก็บข้อมูลที่อ้างอิงเนื้อหา และเบราว์เซอร์พรีมิทีฟด้านความปลอดภัยที่ได้รับการปรับปรุง ล้วนมีบทบาท สิ่งที่ชัดเจนจากการอภิปรายคือเดิมพันสูง — ในขณะที่เว็บแอปพลิเคชันจัดการข้อมูลที่ละเอียดอ่อนมากขึ้นเรื่อยๆ ความต้องการกลไกความสมบูรณ์ของโค้ดที่เชื่อถือได้จึงมีความเร่งด่วนมากขึ้น

ชุมชนทางเทคนิคดูเหมือนจะสอดคล้องกันในความสำคัญของการแก้ปัญหานี้ แม้ในขณะที่ยังคงอภิปรายถึงแนวทางเฉพาะ ดังที่ผู้พัฒนาหนึ่งคนสรุป: ความโปร่งใสของไบนารี (Binary transparency) ช่วยให้คุณสามารถใช้เหตุผลเกี่ยวกับการตรวจสอบได้ของ JavaScript ที่ถูกส่งไปยังเบราว์เซอร์เว็บของคุณ นี่เป็นก้าวสำคัญครั้งแรกสู่โซลูชันสำหรับบล็อกโพสต์ 'JavaScript Cryptography Considered Harmful' การยอมรับนี้ว่าเรากำลังจัดการกับข้อจำกัดทางสถาปัตยกรรมพื้นฐานมากกว่าช่องว่างของฟีเจอร์ง่ายๆ เน้นย้ำว่าทำไมการอภิปรายนี้จึงมีความสำคัญต่ออนาคตของความปลอดภัยบนเว็บ

บทสรุป

การอภิปรายอย่างแข็งขันเกี่ยวกับมาตรฐานความสมบูรณ์ของเว็บแอปพลิเคชันเผยให้เห็นทั้งความเร่งด่วนของปัญหาและความซับซ้อนของโซลูชันที่เป็นไปได้ ในขณะที่การอภิปรายทางเทคนิคยังคงดำเนินต่อไปเกี่ยวกับแนวทางการนำไปปฏิบัติที่ดีที่สุด มีฉันทามติที่ชัดเจนว่าสถานการณ์ปัจจุบันไม่สามารถยอมรับได้สำหรับแอปพลิเคชันที่อ่อนไหวต่อความปลอดภัย หนทางข้างหน้าอาจเกี่ยวข้องกับโซลูชันแบบไฮบริดที่รวมบันทึกความโปร่งใส การลงลายเซ็นด้วยการเข้ารหัส และอาจรวมถึงการจัดเก็บข้อมูลที่อ้างอิงเนื้อหา สิ่งที่แน่นอนคือในขณะที่เว็บแอปพลิเคชันยังคงจัดการข้อมูลผู้ใช้ที่ละเอียดอ่อนมากขึ้นเรื่อยๆ การสร้างความเชื่อมั่นในโค้ดที่ทำงานในเบราว์เซอร์ของเราจะยังคงเป็นความท้าทายที่สำคัญซึ่งต้องอาศัยความร่วมมืออย่างต่อเนื่องระหว่างผู้ขายเบราว์เซอร์ นักวิจัยด้านความปลอดภัย และนักพัฒนาแอปพลิเคชัน การมีส่วนร่วมของชุมชนกับข้อเสนอเหล่านี้แสดงให้เห็นถึงทั้งความสำคัญของปัญหาและความมุ่งมั่นร่วมกันที่จะหาโซลูชันที่ใช้งานได้

อ้างอิง: Improving the trustworthiness of Javascript on the Web