แนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับการรักษาความปลอดภัยแอป

ส่วนนี้มีคำแนะนำเพื่อให้มั่นใจในความปลอดภัยของแอปบน อุปกรณ์ Android

การตรวจสอบซอร์สโค้ด

การตรวจสอบซอร์สโค้ดสามารถตรวจหาปัญหาด้านความปลอดภัยได้หลากหลาย รวมถึงปัญหาที่ระบุไว้ในเอกสารนี้ Android ขอแนะนำให้ตรวจสอบซอร์สโค้ดทั้งด้วยตนเอง และโดยอัตโนมัติ

• ปฏิบัติตามคำแนะนำด้านความปลอดภัยที่ครอบคลุมเมื่อทำการตรวจสอบเพื่อให้มั่นใจถึง ความครอบคลุม ใช้มาตรฐานภายในหรือภายนอกที่เกี่ยวข้องเพื่อให้มั่นใจว่า รีวิวมีความสอดคล้องกันและครบถ้วน
• เรียกใช้โปรแกรมตรวจสอบโค้ด เช่น Android Studio linter ในโค้ดแอปทั้งหมดที่ใช้ Android SDK และแก้ไขปัญหาที่พบ
• วิเคราะห์โค้ดเนทีฟโดยใช้เครื่องมืออัตโนมัติที่ตรวจหาปัญหาการจัดการหน่วยความจำได้ เช่น บัฟเฟอร์ล้นและข้อผิดพลาดแบบออฟบายวัน
• ระบบบิลด์ของ Android รองรับ Sanitizer ของ LLVM หลายรายการ เช่น AddressSanitizer และ UndefinedBehaviorSanitizer ซึ่งใช้ในการวิเคราะห์ปัญหาที่เกี่ยวข้องกับหน่วยความจำในรันไทม์ได้ เมื่อใช้ร่วมกับ การฟัซ ซึ่งรองรับใน Android ผ่าน libFuzzer ตัวทำความสะอาดจะ ค้นพบกรณีขอบที่ผิดปกติซึ่งต้องมีการตรวจสอบเพิ่มเติม
• ผู้ประเมินด้านความปลอดภัยที่มีความรู้ควรตรวจสอบโค้ดที่มีความเสี่ยงสูงกว่า เช่น การเข้ารหัส การประมวลผลการชำระเงิน และการประมวลผล PII

การทดสอบอัตโนมัติ

การทดสอบอัตโนมัติช่วยตรวจหาปัญหาด้านความปลอดภัยได้หลากหลาย และควรดำเนินการเป็นประจำ

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

การสแกนช่องโหว่

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

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

แอปพลิเคชันที่อาจเป็นอันตราย

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับแอปที่อาจเป็นอันตรายและวิธีที่ Google ต่อสู้กับแอปเหล่านี้ใน Play Store ได้ที่เอกสารประกอบสำหรับนักพัฒนาแอปของ Google Play Protect

การติดตั้งและสิทธิ์ของแอป

สิทธิ์ที่มากเกินไปสำหรับแอปที่ติดตั้งไว้ล่วงหน้าอาจก่อให้เกิดความเสี่ยงด้านความปลอดภัย จำกัดสิทธิ์ของแอปที่ติดตั้งไว้ล่วงหน้าให้มีสิทธิ์ขั้นต่ำที่จำเป็น และตรวจสอบว่าแอปเหล่านั้นไม่มีสิทธิ์เข้าถึงสิทธิ์หรือสิทธิพิเศษที่ไม่จำเป็น สิทธิ์ของแอปจะ อธิบายไว้ใน AndroidManifest.xml

• อย่าให้สิทธิ์หรือสิทธิ์ที่ไม่จำเป็นแก่แอปที่ติดตั้งไว้ล่วงหน้า ตรวจสอบแอปที่มีสิทธิ์ระดับระบบอย่างละเอียด เนื่องจากแอปเหล่านี้อาจมีสิทธิ์ที่ละเอียดอ่อนมาก
• ตรวจสอบว่าสิทธิ์ทั้งหมดที่ขอมีความเกี่ยวข้องและจำเป็นต่อ ฟังก์ชันการทำงานของแอปนั้นๆ
• ตรวจสอบว่ามีการเปิดเผยข้อมูลผู้ใช้สำหรับแอปที่ติดตั้งไว้ล่วงหน้าทั้งหมดที่ใช้สิทธิ์ INSTALL_PACKAGES
• ตรวจสอบว่านักพัฒนาแอปมีภาระหน้าที่ตามสัญญาที่จะไม่ติดตั้งแอปใดๆ ในฐานะ UID 0
• ประเมินสิทธิ์ที่ประกาศไว้ในไฟล์ Manifest ของแอปทั้งหมดที่จะติดตั้ง ผ่านเครือข่ายของนักพัฒนาแอป
• ตรวจสอบว่านักพัฒนาแอปมีภาระหน้าที่ตามสัญญาในการสแกน URL การดาวน์โหลดทั้งหมด ของแอปอัปเดตและแอปติดตั้งอัตโนมัติด้วย Google Safe Browsing API ก่อนที่จะแสดงแอปในอุปกรณ์

การลงนามแอป

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

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

แยกแอปและกระบวนการ

โมเดลแซนด์บ็อกซ์ของ Android ช่วยเพิ่มความปลอดภัยให้กับแอปและกระบวนการต่างๆ เมื่อใช้อย่างถูกต้อง

แยกกระบวนการรูท

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

• ตรวจสอบว่าอุปกรณ์เรียกใช้โค้ดที่จำเป็นขั้นต่ำในฐานะรูท หากเป็นไปได้ ให้ใช้กระบวนการ Android ปกติแทนกระบวนการรูท หากต้องเรียกใช้กระบวนการในฐานะรูทในอุปกรณ์ ให้บันทึกกระบวนการในคำขอฟีเจอร์ AOSP เพื่อให้ตรวจสอบได้แบบสาธารณะ
• หากเป็นไปได้ ควรแยกโค้ดรูทออกจากข้อมูลที่ไม่น่าเชื่อถือและ เข้าถึงผ่านการสื่อสารระหว่างกระบวนการ (IPC) เช่น ลดฟังก์ชันการทำงานของรูท ให้เหลือเพียงบริการขนาดเล็กที่เข้าถึงได้ผ่าน Binder และเปิดเผย บริการที่มีสิทธิ์เข้าถึงลายเซ็นให้กับแอปที่มีสิทธิ์ต่ำหรือไม่มีสิทธิ์ ในการจัดการการรับส่งข้อมูลในเครือข่าย
• กระบวนการรูทต้องไม่รับฟังในซ็อกเก็ตเครือข่าย
• กระบวนการรูทต้องไม่มีรันไทม์อเนกประสงค์ เช่น Java VM

แยกแอประบบ

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

• ตรวจสอบว่าอุปกรณ์เรียกใช้โค้ดที่จำเป็นขั้นต่ำในฐานะระบบ หากเป็นไปได้ ให้ใช้กระบวนการ Android ที่มี UID ของตัวเองแทนที่จะใช้ UID ของระบบซ้ำ
• หากเป็นไปได้ ควรแยกโค้ดของระบบออกจากข้อมูลที่ไม่น่าเชื่อถือ และ แสดง IPC เฉพาะต่อกระบวนการอื่นๆ ที่เชื่อถือได้
• กระบวนการของระบบต้องไม่รับฟังในซ็อกเก็ตเครือข่าย นี่เป็นข้อกำหนดของ CTS

แยกกระบวนการ

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

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