นโยบายสำหรับนักพัฒนาแอปและหลักเกณฑ์ด้านความปลอดภัย

Simon Hangl

Demián Renzulli

Isolated Web App (IWA) มีโมเดลความปลอดภัยที่ช่วยให้เว็บแอปพลิเคชันเข้าถึงความสามารถที่มีประสิทธิภาพ เช่น Direct Sockets และ Controlled Frame ซึ่งโดยปกติจะถูกจำกัดในเว็บ "ไดรฟ์บาย" มาตรฐาน เนื่องจาก IWA ทำงานในสภาพแวดล้อมที่มีความน่าเชื่อถือสูง จึงต้องปฏิบัติตามนโยบายด้านความปลอดภัยและความเป็นส่วนตัวที่เข้มงวด หลักเกณฑ์เหล่านี้ออกแบบมาเพื่อให้มั่นใจว่าเมื่อแพลตฟอร์มเว็บมีประสิทธิภาพมากขึ้น ผู้ใช้จะยังคงปลอดภัยและสภาพแวดล้อมของเบราว์เซอร์จะยังคงมีความสมบูรณ์

โมเดลความน่าเชื่อถือของ IWA

หัวใจหลักของแพลตฟอร์ม IWA คือนโยบายทางเทคนิคที่เข้มงวดซึ่งบังคับให้นักพัฒนาแอปต้องรักษาระดับความปลอดภัยสูง ในขณะที่เว็บแอปมาตรฐานอาศัยโมเดลสิทธิ์ที่ยืดหยุ่น IWA จะได้รับการลงนามแบบเข้ารหัสและส่งโดยใช้ Web Bundles ซึ่งช่วยให้ตรวจสอบแหล่งที่มาและความสมบูรณ์ได้

IWA จะได้รับสิทธิ์เข้าถึง API ที่มีสิทธิ์พิเศษเพื่อแลกกับการยืนยันตัวตนนี้ นักพัฒนาแอปต้องใช้แนวทางที่เน้นความปลอดภัยเป็นอันดับแรกโดยปฏิบัติตามนโยบายที่เข้มงวดมากขึ้น ซึ่งรวมถึงนโยบายรักษาความปลอดภัยเนื้อหา (CSP) และประเภทที่เชื่อถือได้ที่มีประสิทธิภาพ เพื่อให้มั่นใจว่าผู้ใช้จะปลอดภัยแม้จะใช้ความสามารถที่มีประสิทธิภาพ ซึ่งหมายความว่า

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

แม้ว่า IWA จะมีการป้องกันในตัวที่แข็งแกร่ง เช่น นโยบายรักษาความปลอดภัยเนื้อหา (CSP) ที่เข้มงวดซึ่งป้องกันการเรียกใช้สคริปต์ภายนอก แต่ข้อจำกัดทางเทคนิคเพียงอย่างเดียวก็ไม่สามารถลดความเสี่ยงได้ทั้งหมด แม้จะอยู่ในสภาพแวดล้อมที่มีความน่าเชื่อถือสูง แต่รูปแบบการติดตั้งใช้งานหรือตัวเลือกของนักพัฒนาแอปบางอย่างอาจทำให้ความปลอดภัยหรือความเป็นส่วนตัวของผู้ใช้ตกอยู่ในความเสี่ยงโดยไม่ตั้งใจ คู่มือนี้จะอธิบายสถานการณ์ที่ถูกจำกัดและนโยบายที่ควบคุมการใช้ API ที่มีสิทธิ์

เหตุผลที่หลักเกณฑ์เหล่านี้มีความสำคัญ

การปฏิบัติตามนโยบายเหล่านี้ไม่ได้มีไว้เพื่อการปฏิบัติตามข้อกำหนดเท่านั้น แต่ยังเป็นการสร้างระบบนิเวศที่ยั่งยืนสำหรับเว็บแอปพลิเคชันขั้นสูงด้วย การปฏิบัติตามหลักเกณฑ์เหล่านี้จะช่วยให้แอปพลิเคชันของคุณมีคุณสมบัติดังนี้

• หลีกเลี่ยงการถดถอยด้านความปลอดภัย: ป้องกันช่องโหว่ เช่น Cross-Site Scripting (XSS) และการเรียกใช้โค้ดจากระยะไกลด้วยการเก็บตรรกะไว้ในตัวเอง
• ปกป้องความเป็นส่วนตัวของผู้ใช้: รับรองว่ามีการจัดการข้อมูลที่ละเอียดอ่อนและการเข้าถึงฮาร์ดแวร์โดยมีเจตนาและความโปร่งใสของผู้ใช้ที่ชัดเจนเท่านั้น
• รับประกันอายุการใช้งานของแพลตฟอร์ม: ช่วยรักษามาตรฐานความปลอดภัยระดับสูงที่จำเป็นสำหรับแพลตฟอร์ม IWA เพื่อขยายชุดความสามารถต่อไป

หลักการสำคัญ

ความโปร่งใสและความตั้งใจของผู้ใช้

กฎพื้นฐานที่สุดคืออย่าทำให้ผู้ใช้ประหลาดใจ ลักษณะการทำงานของแอปพลิเคชันต้องสอดคล้องกับวัตถุประสงค์ที่ระบุไว้และความคาดหวังของผู้ใช้

• อยู่ในขอบเขต: อย่าใช้ฟังก์ชันการทำงานที่นอกเหนือจากวัตถุประสงค์ที่ชัดเจนของแอปพลิเคชัน
• ร่องรอย API ขั้นต่ำ: ขอและใช้ชุด API ของ IWA ที่เฉพาะเจาะจงที่จำเป็นต่อการบรรลุฟังก์ชันหลักของแอปเท่านั้น

ไม่มีการโหลดโค้ดแบบไดนามิกจากภายนอก

โมเดลความปลอดภัยของ IWA ขึ้นอยู่กับความสามารถของผู้ดูแลระบบหรือผู้ให้บริการเบราว์เซอร์ในการยืนยันตรรกะที่เรียกใช้งานได้ทั้งหมด ดังนั้น แพ็กเกจ IWA ของคุณจึงต้องมีทุกอย่างครบถ้วนในตัว แพลตฟอร์มบังคับใช้ข้อกำหนดนี้ผ่านนโยบายรักษาความปลอดภัยเนื้อหา (CSP) ที่เข้มงวดซึ่งบล็อกการดำเนินการตามสตริง เช่น eval() และ new Function()

script-src 'self' 'wasm-unsafe-eval';
require-trusted-types-for 'script';

แม้ว่า CSP จะอนุญาตให้ 'wasm-unsafe-eval' รองรับ WebAssembly แต่คุณต้องไม่หลีกเลี่ยงเจตนารมณ์ของขอบเขตความปลอดภัยนี้

การปฏิบัติที่ไม่อนุญาตโดยเด็ดขาด

• การจัดส่งอินเทอร์พรีเตอร์สำหรับรีโมตโค้ด: คุณต้องไม่รวมอินเทอร์พรีเตอร์ของโค้ด (เช่น Python หรือ Lua ที่คอมไพล์เป็น WASM) เพื่อดาวน์โหลดและเรียกใช้สคริปต์ภายนอกโดยใช้สิทธิ์เข้าถึงเครือข่ายที่มีสิทธิ์ เช่น Direct Sockets
• ตรรกะที่โหลดจากระยะไกล: อย่าใช้ Service Worker เพื่อฝังโค้ดที่โหลดจากระยะไกลลงในต้นทางของ IWA
• โค้ดเทียบกับข้อมูล: แม้ว่าจะได้รับอนุญาตให้ดาวน์โหลดข้อมูล (เช่น JSON) แต่การดาวน์โหลดโค้ดใดๆ ที่มีจุดประสงค์เพื่อตีความหรือเรียกใช้ถือเป็นการละเมิดนโยบายโดยตรง

หลักการให้สิทธิ์ขั้นต่ำที่สุด

ใช้ API ที่มีประสิทธิภาพน้อยที่สุดที่สามารถทำงานให้สำเร็จได้เสมอ ไม่ควรใช้ API เฉพาะ IWA ที่มีสิทธิ์เป็นทางลัดเพื่อหลีกเลี่ยงข้อจำกัดด้านความปลอดภัยหรือข้อความแจ้งของผู้ใช้ของ Web API มาตรฐาน ตารางต่อไปนี้แสดงกรณีการใช้งานทั่วไปเพื่อช่วยคุณตัดสินใจว่าจะใช้ Web API แบบเดิมหรือความสามารถเฉพาะของ IWA เมื่อใด

หลักเกณฑ์เฉพาะ API

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

Direct Sockets API

Direct Sockets API ให้สิทธิ์เข้าถึง TCP และ UDP แบบดิบ ซึ่งรวมถึงการเข้าถึงแบบหลายผู้รับและการเข้าถึงเครือข่าย LAN

อนุญาต

• รองรับโปรโตคอลที่กำหนดเอง: เชื่อมต่อกับเซิร์ฟเวอร์ระยะไกลที่ใช้โปรโตคอลที่กำหนดเองซึ่งปัจจุบันไม่มี Web API ระดับสูงกว่า
• การบำรุงรักษาบริการแบ็กเอนด์: การเชื่อมต่อกับเซิร์ฟเวอร์ที่กำหนดไว้ล่วงหน้าและฮาร์ดโค้ดซึ่งใช้เฉพาะสำหรับบริการแบ็กเอนด์ของแอปพลิเคชัน
• การค้นหาฮาร์ดแวร์ที่จำเป็น: การเข้าถึงเครือข่ายภายในหรือการใช้การส่งแบบหลายผู้รับเพื่อค้นหาฮาร์ดแวร์ที่เกี่ยวข้องและเฉพาะเจาะจงซึ่งจำเป็นต่อฟังก์ชันของแอป (เช่น แอปตัดต่อวิดีโอที่ค้นหาที่เก็บข้อมูลที่เชื่อมต่อเครือข่าย)

ไม่อนุญาต

• สร้างความประหลาดใจให้ผู้ใช้: การใช้สิทธิ์เข้าถึงเครือข่ายที่ฟังก์ชันการทำงานหลักของแอปไม่ได้อธิบายไว้อย่างชัดเจน เช่น โปรแกรมแก้ไขข้อความที่สื่อสารกับอุปกรณ์ในเครือข่ายท้องถิ่น
• การสแกนเครือข่ายโดยพลการ: การสแกนเครือข่ายท้องถิ่นของผู้ใช้ในวงกว้าง (เช่น การสแกนพอร์ต 192.168.1.0/24) เพื่อสร้างโปรไฟล์ผู้ใช้หรือค้นหาอุปกรณ์ที่ไม่เกี่ยวข้อง
• การกำหนดเป้าหมายอุปกรณ์ในเครือข่ายภายใน: เราไม่อนุญาตให้พยายามตรวจสอบ กำหนดค่าใหม่ หรือโจมตีอุปกรณ์อื่นๆ ในเครือข่ายภายในโดยเด็ดขาด

Controlled Frame API

องค์ประกอบ <controlledframe> อนุญาตให้ฝังและแก้ไขเนื้อหาข้ามต้นทาง รวมถึงการแอบฝังสคริปต์และการเปลี่ยนแปลงส่วนหัว

อนุญาต

• การปรับปรุงอินเทอร์เฟซผู้ใช้: การฝังบริการของบุคคลที่สามและการแทรก CSS เพื่อซ่อนองค์ประกอบ UI ที่ไม่เกี่ยวข้องหรือมอบประสบการณ์การใช้งานที่สอดคล้องกันมากขึ้น
• เป็นตัวกลางในการสื่อสารที่ปลอดภัย: ทำหน้าที่เป็นผู้ควบคุมโดยรับคำขอจากหน้าเว็บที่ฝังด้วย postMessage และส่งคืนเฉพาะข้อมูลที่จำเป็นซึ่งผ่านการล้างข้อมูลแล้วซึ่งดึงข้อมูลผ่าน API ที่มีสิทธิ์

ไม่อนุญาต

• การขโมยข้อมูลเข้าสู่ระบบของผู้ใช้: การแทรกสคริปต์เพื่อบันทึกรหัสผ่าน คุกกี้เซสชัน หรือข้อมูลผู้ใช้ที่ละเอียดอ่อนอื่นๆ จากเนื้อหาที่ฝัง
• การละเมิดข้อกำหนดในการให้บริการ: การดัดแปลงแพลตฟอร์มที่ฝังในลักษณะที่ละเมิดข้อกำหนดในการให้บริการ เช่น การคลิกโฆษณาแบบเป็นโปรแกรมหรือการคัดลอกเนื้อหาโดยไม่ได้รับอนุญาต
• การพร็อกซีการเข้าถึงที่มีสิทธิ์: การสร้างการส่งผ่านที่ให้เนื้อหาแบบฝังที่ไม่น่าเชื่อถือเข้าถึง IWA API ที่มีสิทธิ์โดยตรงหรือแบบไม่มีการควบคุม
• การใช้ AI ที่ไม่มีการควบคุม: การดำเนินการในนามของผู้ใช้ที่เข้าสู่ระบบผ่าน AI โดยไม่มีข้อจำกัดของ Use Case ที่เฉพาะเจาะจงและโปร่งใส

การบันทึกหน้าจอแบบไม่จำกัด

อนุญาตให้จับภาพหน้าจอโดยไม่ต้องแจ้งให้ผู้ใช้ให้สิทธิ์ซ้ำๆ เหมือนในเว็บมาตรฐาน

อนุญาต

• การให้บริการฟังก์ชันหลัก: การใช้การจับภาพหน้าจอเป็นส่วนที่เห็นได้ชัดของบริการของแอป เช่น ในฟีเจอร์การประชุมเสมือนหรือการบันทึกวิดีโอสอน
• สร้างการรับรู้ของผู้ใช้: แจ้งให้ผู้ใช้ทราบอย่างชัดเจนว่าอาจมีการบันทึกก่อนที่ผู้ใช้จะมีส่วนร่วมกับแอปพลิเคชัน

ไม่อนุญาต

• การบันทึกอย่างลับๆ: การจับภาพหน้าจอของผู้ใช้โดยที่ผู้ใช้ไม่ทราบและไม่ได้ให้ความยินยอมอย่างชัดเจนล่วงหน้า
• ละเมิดกฎระเบียบด้านความเป็นส่วนตัว: การมีส่วนร่วมในแนวทางการบันทึกใดๆ ที่ละเมิดกฎหมายความเป็นส่วนตัวในท้องถิ่นหรือระหว่างประเทศ

WebUSB ที่ไม่จำกัด

WebUSB ที่ไม่จำกัดจะข้ามรายการที่บล็อก WebUSB มาตรฐานเพื่อให้มีการโต้ตอบระดับต่ำกับอุปกรณ์

อนุญาต

• รองรับฮาร์ดแวร์ที่เป็นกรรมสิทธิ์: การโต้ตอบกับฮาร์ดแวร์เฉพาะทางหรือฮาร์ดแวร์รุ่นเก่าที่ไม่มี Web API ระดับสูง เช่น คอนโทรลเลอร์อุตสาหกรรม

อนุญาตแล้ว

• การข้าม API เฉพาะ: การใช้ WebUSB สำหรับอุปกรณ์ที่มี API ที่เฉพาะเจาะจงและจำกัดมากกว่า เช่น สมาร์ทการ์ด (ใช้ Smart Card API) หรือที่เก็บข้อมูลภายนอก (ใช้ File System Access API)

การจัดการหน้าต่าง (window.open และ window.focus)

IWA สามารถสร้างป๊อปอัปและโฟกัสหน้าต่างได้โดยไม่ต้องใช้ท่าทางของผู้ใช้ตามที่เว็บมาตรฐานกำหนด

อนุญาต

• การแจ้งเตือนเมื่องานเสร็จสมบูรณ์: โฟกัสหน้าต่างแอปเมื่องานเบื้องหลังที่สำคัญซึ่งเริ่มต้นโดยผู้ใช้ เช่น การเรนเดอร์วิดีโอ เสร็จสมบูรณ์

ไม่อนุญาต

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

บทสรุป

สถาปัตยกรรมความปลอดภัยของ Isolated Web App ออกแบบมาเพื่อช่วยให้นักพัฒนาแอปทำงานได้ดียิ่งขึ้นในขณะที่ยังคงรักษาสภาพแวดล้อมที่มีความน่าเชื่อถือสูงสำหรับผู้ใช้ การปฏิบัติตามหลักเกณฑ์เหล่านี้จะช่วยให้มั่นใจได้ว่าแอปพลิเคชันของคุณยังคงเป็นส่วนหนึ่งของระบบนิเวศ IWA อย่างมีความรับผิดชอบ ประเด็นสำคัญที่สุดจากคู่มือนี้ ได้แก่

• ให้ความสำคัญกับความโปร่งใส: พฤติกรรมของแอปพลิเคชันควรสอดคล้องกับวัตถุประสงค์ที่ระบุไว้เสมอ และไม่ควรใช้ฟังก์ชันการทำงานที่ทำให้ผู้ใช้ประหลาดใจหรือทำให้ผู้ใช้รู้สึกว่าถูกหลอก
• บังคับใช้ความสมบูรณ์ของแพ็กเกจ: ตรรกะที่เรียกใช้งานได้ทั้งหมดต้องอยู่ในแพ็กเกจ IWA ของคุณเองเพื่อให้สามารถทำการยืนยันแบบคงที่ได้ เราห้ามอย่างเด็ดขาดไม่ให้มีการข้ามโมเดลความปลอดภัยผ่านการโหลดโค้ดแบบไดนามิกด้านข้างหรือการใช้ตัวแปลภาษาจากระยะไกล
• ปฏิบัติตามหลักการสิทธิ์น้อยที่สุด: เลือก API ที่มีข้อจำกัดมากที่สุดเสมอสำหรับงานที่กำหนด ควรใช้ API ของ IWA ที่มีสิทธิ์ก็ต่อเมื่อ Web API มาตรฐานไม่เพียงพอสำหรับฟังก์ชันหลักของแอปพลิเคชัน
• ทำหน้าที่เป็นผู้ควบคุม: เมื่อใช้เครื่องมือที่มีประสิทธิภาพอย่าง <controlledframe> IWA ของคุณต้องทำหน้าที่เป็นตัวกลางที่ปลอดภัยแทนที่จะเป็นพร็อกซีแบบโปร่งใสสำหรับเนื้อหาที่ไม่น่าเชื่อถือ

ก่อนเผยแพร่ IWA ให้ตรวจสอบการติดตั้งใช้งานครั้งสุดท้ายโดยถามคำถามต่อไปนี้

1. ฉันใช้ API ที่ง่ายที่สุดและมีข้อจำกัดมากที่สุดสำหรับงานนี้หรือไม่
2. ผู้ใช้จะประหลาดใจหรือรู้สึกว่าถูกแอปของฉันหลอกไหม

หากคำตอบของคำถามแรกคือ "ไม่" หรือคำตอบของคำถามที่สองคือ "ใช่" แสดงว่าแอปพลิเคชันของคุณอาจละเมิดนโยบายด้านความปลอดภัยของ IWA และอาจถูกนำออก