Google มุ่งมั่นที่จะพัฒนาความเท่าเทียมทางเชื้อชาติสำหรับชุมชนคนผิวดำ มาดูกันว่า
หน้านี้ได้รับการแปลโดย Cloud Translation API
Switch to English

แนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยของแอพ

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

ตรวจสอบรหัสต้นฉบับ

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

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

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

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

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

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

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

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

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

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

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

การติดตั้งแอพและการอนุญาต

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

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

การลงชื่อแอป

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

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

การแยกแอพและกระบวนการต่าง ๆ

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

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

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

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

การแยกแอประบบ

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

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

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

Android Application Sandbox ให้แอปพลิเคชั่นคาดหวังว่าจะมีการแยกออกจากกระบวนการอื่น ๆ ในระบบรวมถึงกระบวนการรูทและดีบั๊ก แอพและผู้ใช้จะไม่สามารถทำการดีบักได้เว้นแต่จะทำการดีบั๊กแล้ว

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