ส่วนนี้ประกอบด้วยคําแนะนําเพื่อรักษาความปลอดภัยของแอปในอุปกรณ์ Android
การตรวจสอบซอร์สโค้ด
การตรวจสอบซอร์สโค้ดสามารถตรวจหาปัญหาด้านความปลอดภัยได้หลากหลาย รวมถึงปัญหาที่ระบุไว้ในเอกสารนี้ Android ขอแนะนำให้ตรวจสอบซอร์สโค้ดทั้งแบบอัตโนมัติและแบบเจ้าหน้าที่
- ปฏิบัติตามคำแนะนำด้านความปลอดภัยที่ครอบคลุมเมื่อทำการตรวจสอบเพื่อให้ครอบคลุม ใช้มาตรฐานภายในหรือภายนอกที่เกี่ยวข้องเพื่อให้แน่ใจว่าการตรวจสอบจะสอดคล้องกันและสมบูรณ์
- เรียกใช้โปรแกรมตรวจไวยากรณ์ เช่น โปรแกรมตรวจไวยากรณ์ของ Android Studio ในโค้ดแอปทั้งหมดที่ใช้ Android SDK และแก้ไขปัญหาที่พบ
- วิเคราะห์โค้ดเนทีฟโดยใช้เครื่องมืออัตโนมัติที่สามารถตรวจหาปัญหาการจัดการหน่วยความจำ เช่น บัฟเฟอร์ที่ล้น และข้อผิดพลาดที่มากกว่า 1
- ระบบการสร้างของ Android รองรับโปรแกรมตรวจสอบ LLVM หลายรายการ เช่น AddressSanitizer และ UndefinedBehaviorSanitizer ซึ่งสามารถใช้สำหรับการวิเคราะห์ปัญหาเกี่ยวกับหน่วยความจำที่เกิดขึ้นขณะรันไทม์ เมื่อใช้ร่วมกับการทดสอบแบบ Fuzzing ซึ่ง Android รองรับผ่าน libFuzzer โปรแกรมตรวจสอบสามารถตรวจหากรณีขอบที่ไม่ปกติซึ่งต้องตรวจสอบเพิ่มเติม
- ผู้ประเมินความปลอดภัยที่มีความรู้ควรตรวจสอบโค้ดที่มีความเสี่ยงสูง เช่น คริปโต การชำระเงิน และการประมวลผล PII
การทดสอบอัตโนมัติ
การทดสอบอัตโนมัติช่วยตรวจหาปัญหาด้านความปลอดภัยได้หลากหลายและควรทำเป็นประจำ
- เรียกใช้ CTS เวอร์ชันล่าสุดเป็นประจำตลอดกระบวนการพัฒนาเพื่อตรวจหาปัญหาตั้งแต่เนิ่นๆ และลดเวลาในการแก้ไข Android ใช้ CTS เป็นส่วนหนึ่งของการผสานรวมอย่างต่อเนื่องในกระบวนการบิลด์อัตโนมัติของเรา ซึ่งจะบิลด์หลายครั้งต่อวัน
- ทำการทดสอบความปลอดภัยของอินเทอร์เฟซโดยอัตโนมัติ รวมถึงการทดสอบด้วยอินพุตที่มีรูปแบบไม่ถูกต้อง (การทดสอบแบบ Fuzz) ระบบบิลด์ของ Android รองรับ libFuzzer สำหรับการเขียนการทดสอบแบบ Fuzz
การสแกนช่องโหว่
การสแกนหาช่องโหว่ช่วยให้มั่นใจได้ว่าแอปที่ติดตั้งไว้ล่วงหน้าจะไม่มีช่องโหว่ด้านความปลอดภัยที่ทราบ การตรวจหาขั้นสูงจะช่วยลดเวลาและค่าใช้จ่ายในการแก้ไขช่องโหว่เหล่านี้และป้องกันความเสี่ยงต่อผู้ใช้และอุปกรณ์
- สแกนแอปที่ติดตั้งไว้ล่วงหน้าทั้งหมดโดยใช้เครื่องมือสแกนช่องโหว่ของแอปที่ได้รับการยอมรับในอุตสาหกรรม และแก้ไขช่องโหว่ที่ตรวจพบ
แอปพลิเคชันที่อาจเป็นอันตราย
คุณต้องตรวจสอบว่าแอปที่ติดตั้งมาล่วงหน้าในอุปกรณ์ไม่ใช่แอปพลิเคชันที่อาจเป็นอันตราย (PHA) คุณมีหน้าที่รับผิดชอบต่อลักษณะการทํางานของแอปทั้งหมดที่มีอยู่ในอุปกรณ์ ก่อนเปิดตัวอุปกรณ์ ให้สแกนแอปที่โหลดไว้ล่วงหน้าทั้งหมดเพื่อหาช่องโหว่
ดูข้อมูลเพิ่มเติมเกี่ยวกับ 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 ที่บันทึกไว้
- ตรวจสอบว่าอุปกรณ์ไม่มีแอปที่เข้าถึงข้อมูลหรือหน่วยความจำของแอปหรือกระบวนการอื่นๆ