รายการตรวจสอบการรักษาความปลอดภัย

จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ

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

ฟีเจอร์ด้านความปลอดภัยหลักต่อไปนี้จะช่วยคุณสร้างแอปที่ปลอดภัย

• แซนด์บ็อกซ์แอปพลิเคชันของ Android ซึ่งแยกข้อมูลแอปและการดำเนินการของโค้ดออกจากแอปอื่นๆ
• เฟรมเวิร์กแอปพลิเคชันที่มีการใช้งานฟังก์ชันการทำงานด้านความปลอดภัยทั่วไปที่มีประสิทธิภาพ เช่น วิทยาการเข้ารหัส สิทธิ์ และการสื่อสารระหว่างกระบวนการที่ปลอดภัย (IPC)
• เทคโนโลยีต่างๆ เช่น Address Space Layout Randomization (ASLR), No-Execute (NX), ProPolice, safe_iop, OpenBSD dlmalloc และ calloc รวมถึง Linux mmap_min_addr เพื่อลดความเสี่ยงที่เกี่ยวข้องกับข้อผิดพลาดด้านการจัดการหน่วยความจำที่พบได้ทั่วไป
• สิทธิ์ที่ผู้ใช้ให้ไว้เพื่อจำกัดการเข้าถึงฟีเจอร์ของระบบและข้อมูลผู้ใช้
• สิทธิ์ที่แอปพลิเคชันกำหนดเพื่อควบคุมข้อมูลแอปพลิเคชันในแต่ละแอป

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

การตรวจสอบสิทธิ์

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

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

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

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

ความสมบูรณ์ของแอป

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

การจัดเก็บข้อมูล

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

• ที่เก็บข้อมูลภายใน
• ที่จัดเก็บข้อมูลภายนอก
• ผู้ให้บริการเนื้อหา

ส่วนต่อไปนี้จะอธิบายปัญหาด้านความปลอดภัยที่เกี่ยวข้องกับแนวทางแต่ละวิธี

ที่เก็บข้อมูลภายใน

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

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

ที่จัดเก็บข้อมูลภายนอก

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

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

ผู้ให้บริการเนื้อหา

ผู้ให้บริการเนื้อหามีกลไกพื้นที่เก็บข้อมูลที่จัดโครงสร้างไว้ซึ่งสามารถจำกัดไว้สำหรับแอปพลิเคชันของคุณเองหรือส่งออกเพื่ออนุญาตให้แอปพลิเคชันอื่นๆ เข้าถึงได้ หากคุณไม่ได้ตั้งใจจะให้สิทธิ์เข้าถึง ContentProvider แก่แอปพลิเคชันอื่นๆ ให้ทำเครื่องหมายเป็น android:exported=false ในไฟล์ Manifest ของแอปพลิเคชัน หรือตั้งค่าแอตทริบิวต์ android:exported เป็น true เพื่อให้แอปอื่นๆ เข้าถึงข้อมูลที่จัดเก็บไว้ได้

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

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

นอกจากนี้ ผู้ให้บริการเนื้อหายังให้สิทธิ์เข้าถึงที่ละเอียดยิ่งขึ้นได้ด้วยโดยการประกาศแอตทริบิวต์ android:grantUriPermissions และใช้ Flag FLAG_GRANT_READ_URI_PERMISSION และ FLAG_GRANT_WRITE_URI_PERMISSION ในออบเจ็กต์ Intent ที่เปิดใช้งานคอมโพเนนต์ ขอบเขตของสิทธิ์เหล่านี้สามารถจํากัดเพิ่มเติมได้โดยใช้องค์ประกอบ <grant-uri-permission>

เมื่อเข้าถึงผู้ให้บริการเนื้อหา ให้ใช้เมธอดการค้นหาแบบพารามิเตอร์ เช่น query, update และ delete() เพื่อหลีกเลี่ยงการแทรก SQL ที่อาจเกิดขึ้นจากแหล่งที่มาที่ไม่น่าเชื่อถือ โปรดทราบว่าการใช้เมธอดที่มีพารามิเตอร์นั้นไม่เพียงพอหากสร้างอาร์กิวเมนต์ selection โดยการต่อข้อมูลผู้ใช้ก่อนส่งไปยังเมธอด

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

สิทธิ์

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

คำขอสิทธิ์

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

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

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

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

คำจำกัดความของสิทธิ์

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

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

หากยังคงต้องสร้างสิทธิ์ใหม่ ให้ประกาศสิทธิ์นั้นในไฟล์ Manifest ของแอปโดยใช้องค์ประกอบ <permission> แอปที่ใช้สิทธิ์ใหม่จะอ้างอิงสิทธิ์ดังกล่าวได้โดยเพิ่มองค์ประกอบ <uses-permission> ในไฟล์ Manifest นอกจากนี้ คุณยังเพิ่มสิทธิ์แบบไดนามิกได้โดยใช้เมธอด addPermission()

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

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

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

เครือข่าย

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

เครือข่าย IP

เครือข่ายใน Android ไม่ได้แตกต่างจากสภาพแวดล้อม Linux อื่นๆ มากนัก สิ่งที่ควรพิจารณาหลักๆ คือการใช้โปรโตคอลที่เหมาะสมกับข้อมูลที่ละเอียดอ่อน เช่น HttpsURLConnection สำหรับการรับส่งข้อมูลในเว็บอย่างปลอดภัย ใช้ HTTPS แทน HTTP ในทุกที่ที่เซิร์ฟเวอร์รองรับ HTTPS เนื่องจากอุปกรณ์เคลื่อนที่มักเชื่อมต่อกับเครือข่ายที่ไม่ปลอดภัย เช่น ฮอตสปอต Wi-Fi สาธารณะ

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

แอปพลิเคชันบางรายการใช้พอร์ตเครือข่าย localhost เพื่อจัดการ IPC ที่มีความละเอียดอ่อน อย่าใช้แนวทางนี้เนื่องจากแอปพลิเคชันอื่นๆ ในอุปกรณ์สามารถเข้าถึงอินเทอร์เฟซเหล่านี้ได้ แต่ให้ใช้กลไก IPC ของ Android ที่ทําให้ได้สิทธิ์เข้าถึง เช่น Service การเชื่อมโยงกับที่อยู่ IP ที่ไม่เจาะจง INADDR_ANY นั้นแย่กว่าการใช้ loopback เนื่องจากอนุญาตให้แอปพลิเคชันของคุณรับคําขอจากที่อยู่ IP ใดก็ได้

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

เครือข่ายโทรศัพท์

โปรโตคอลการรับส่งข้อความสั้น (SMS) ออกแบบมาเพื่อการสื่อสารระหว่างผู้ใช้เป็นหลัก และไม่เหมาะกับแอปที่ต้องการโอนข้อมูล เนื่องจากข้อจํากัดของ SMS เราขอแนะนําให้ใช้ Firebase Cloud Messaging (FCM) และเครือข่าย IP สําหรับส่งข้อความข้อมูลจากเว็บเซิร์ฟเวอร์ไปยังแอปในอุปกรณ์ของผู้ใช้

โปรดทราบว่า SMS ไม่ได้เข้ารหัสหรือตรวจสอบสิทธิ์อย่างเข้มงวดในเครือข่ายหรืออุปกรณ์ โดยเฉพาะอย่างยิ่ง ผู้รับ SMS ควรทราบว่าผู้ใช้ที่เป็นอันตรายอาจส่ง SMS ไปยังแอปพลิเคชันของคุณ อย่าใช้ข้อมูล SMS ที่ไม่มีการรับรองเพื่อดำเนินการกับคําสั่งที่มีความละเอียดอ่อน นอกจากนี้ โปรดทราบว่า SMS อาจมีการปลอมแปลงและ/หรือการดักรับในเครือข่าย ในอุปกรณ์ที่ทำงานด้วยระบบ Android เอง ระบบจะส่งข้อความ SMS เป็น Intent แบบออกอากาศเพื่อให้แอปพลิเคชันอื่นๆ ที่มีสิทธิ์READ_SMS อ่านหรือบันทึกข้อความได้

การตรวจสอบข้อมูลที่ป้อน

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

หากคุณใช้โค้ดเนทีฟ ข้อมูลที่อ่านจากไฟล์ ข้อมูลที่รับผ่านเครือข่าย หรือข้อมูลที่รับจาก IPC อาจก่อให้เกิดปัญหาด้านความปลอดภัย ปัญหาที่พบบ่อยที่สุดคือ บัฟเฟอร์ล้น การใช้หลังจากมีการปลด และข้อผิดพลาดที่เพิ่มขึ้น 1 รายการ Android มีเทคโนโลยีหลายอย่าง เช่น ASLR และการป้องกันการดำเนินการกับข้อมูล (DEP) ที่ช่วยลดโอกาสในการใช้ประโยชน์จากข้อผิดพลาดเหล่านี้ แต่ไม่ได้แก้ปัญหาพื้นฐาน คุณสามารถป้องกันช่องโหว่เหล่านี้ได้ด้วยการจัดการพอยน์เตอร์และบัฟเฟอร์อย่างระมัดระวัง

ภาษาแบบไดนามิกที่อิงตามสตริง เช่น JavaScript และ SQL ยังอาจมีปัญหาเกี่ยวกับการตรวจสอบอินพุตเนื่องจากอักขระหลีกและการแทรกสคริปต์

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

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

ข้อมูลผู้ใช้

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

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

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

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

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

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

WebView

เนื่องจาก WebView ใช้เนื้อหาเว็บที่อาจมี HTML และ JavaScript การใช้ที่ไม่เหมาะสมอาจทำให้เกิดปัญหาด้านความปลอดภัยของเว็บที่พบได้ทั่วไป เช่น Cross-site Scripting (การแทรก JavaScript) Android มีกลไกต่างๆ ในการลดขอบเขตของปัญหาที่อาจเกิดขึ้นเหล่านี้ด้วยการกำหนดขีดความสามารถของ WebView ให้อยู่ในระดับฟังก์ชันการทำงานขั้นต่ำที่แอปพลิเคชันของคุณต้องใช้

หากแอปพลิเคชันของคุณไม่ได้ใช้ JavaScript ภายใน WebView โดยตรง อย่าเรียกใช้ setJavaScriptEnabled โค้ดตัวอย่างบางรายการใช้เมธอดนี้ หากคุณนําโค้ดตัวอย่างที่ใช้เมธอดนี้ไปใช้ใหม่ในแอปพลิเคชันเวอร์ชันที่ใช้งานจริง ให้นําการเรียกใช้เมธอดนั้นออกหากไม่จําเป็น โดยค่าเริ่มต้น WebView จะไม่เรียกใช้ JavaScript ดังนั้นจึงไม่สามารถเกิด Cross-site Scripting ได้

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

หากแอปพลิเคชันของคุณเข้าถึงข้อมูลที่ละเอียดอ่อนด้วย WebView ให้พิจารณาใช้วิธี clearCache() เพื่อลบไฟล์ที่เก็บไว้ในเครื่อง นอกจากนี้ คุณยังใช้ส่วนหัวฝั่งเซิร์ฟเวอร์ เช่น no-store เพื่อระบุว่าแอปพลิเคชันไม่ควรแคชเนื้อหาบางอย่างได้ด้วย

อุปกรณ์ที่ใช้แพลตฟอร์มเก่ากว่า Android 4.4 (API ระดับ 19) ใช้ webkit เวอร์ชันที่มีปัญหาด้านความปลอดภัยหลายประการ วิธีแก้ปัญหาคือ หากแอปของคุณทำงานในอุปกรณ์เหล่านี้ แอปต้องยืนยันว่าออบเจ็กต์ WebView จะแสดงเฉพาะเนื้อหาที่เชื่อถือได้ โปรดใช้ออบเจ็กต์ความปลอดภัย Provider ที่อัปเดตได้ตามที่อธิบายไว้ในอัปเดตผู้ให้บริการรักษาความปลอดภัยเพื่อป้องกันการแสวงหาประโยชน์จาก SSL เพื่อให้มั่นใจว่าแอปของคุณจะไม่เสี่ยงต่อช่องโหว่ที่อาจเกิดขึ้นใน SSL หากแอปพลิเคชันต้องแสดงผลเนื้อหาจากเว็บแบบเปิด ให้พิจารณาระบุโปรแกรมแสดงผลของคุณเองเพื่อให้อัปเดตโปรแกรมแสดงผลเป็นแพตช์ความปลอดภัยล่าสุดอยู่เสมอ

คำขอข้อมูลเข้าสู่ระบบ

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

ลดการแสดงข้อมูลเข้าสู่ระบบ

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

ใช้การตรวจสอบสิทธิ์ที่ปลอดภัย

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

ฝึกจัดการบัญชีอย่างปลอดภัย

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

โปรดระมัดระวัง

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

การจัดการคีย์ API

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

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

ส่วนนี้มีไว้สำหรับนักพัฒนาแอป Android 2 กลุ่ม ได้แก่ ผู้ทํางานร่วมกับทีมโครงสร้างพื้นฐานในไปป์ไลน์การนำส่งแบบต่อเนื่อง และผู้ที่ใช้แอปแบบสแตนด์อโลนใน Play Store ส่วนนี้จะกล่าวถึงแนวทางปฏิบัติแนะนำสำหรับวิธีจัดการคีย์ API เพื่อให้แอปสื่อสารกับบริการได้อย่างปลอดภัย

การสร้างและการจัดเก็บ

นักพัฒนาแอปควรถือว่าพื้นที่เก็บข้อมูลคีย์ API เป็นองค์ประกอบสําคัญของการป้องกันข้อมูลและความเป็นส่วนตัวของผู้ใช้โดยใช้แนวทางการป้องกันแบบหลายชั้น

พื้นที่เก็บข้อมูลคีย์ที่ปลอดภัย

ใช้ Android Keystore และเข้ารหัสคีย์ที่เก็บไว้โดยใช้เครื่องมือที่มีประสิทธิภาพ เช่น Tink Java เพื่อรักษาความปลอดภัยในการจัดการคีย์ที่ดีที่สุด

การยกเว้นการควบคุมแหล่งที่มา

อย่าคอมมิตคีย์ API ไปยังที่เก็บซอร์สโค้ด การเพิ่มคีย์ API ลงในซอร์สโค้ดอาจทำให้คีย์ดังกล่าวเสี่ยงที่จะเปิดเผยต่อที่เก็บข้อมูลสาธารณะ ตัวอย่างโค้ดที่แชร์ และไฟล์ที่แชร์โดยไม่ตั้งใจ แต่ให้ใช้ปลั๊กอิน Gradle เช่น secrets-gradle-plugin เพื่อทำงานกับคีย์ API ในโปรเจ็กต์แทน

คีย์เฉพาะสภาพแวดล้อม

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

การใช้งานและการควบคุมการเข้าถึง

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

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

หมายเหตุ: บริการของคุณควรมีฟีเจอร์ในการจำกัดคีย์ไว้สำหรับแพ็กเกจหรือแพลตฟอร์มหนึ่งๆ เช่น Google Maps API จำกัดการเข้าถึงคีย์ตามชื่อแพ็กเกจและคีย์ App Signing

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

การหมุนเวียนและวันหมดอายุของคีย์

คุณควรเปลี่ยนคีย์ API เป็นประจําเพื่อลดความเสี่ยงที่จะมีการเข้าถึงโดยไม่ได้รับอนุญาตผ่านช่องโหว่ของ API ที่ยังไม่ค้นพบ มาตรฐาน ISO 27001 กําหนดกรอบการปฏิบัติตามข้อกําหนดเกี่ยวกับความถี่ในการเปลี่ยนคีย์ ในกรณีส่วนใหญ่ ระยะเวลาการหมุนเวียนคีย์ระหว่าง 90 วันถึง 6 เดือนก็เพียงพอแล้ว การใช้ระบบจัดการคีย์ที่มีประสิทธิภาพจะช่วยคุณปรับปรุงกระบวนการเหล่านี้ให้ดียิ่งขึ้น ซึ่งจะเพิ่มประสิทธิภาพของการเปลี่ยนคีย์และความต้องการในการหมดอายุ

แนวทางปฏิบัติแนะนำโดยทั่วไป

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

วิทยาการเข้ารหัสลับ

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

ทราบว่าซอฟต์แวร์ของคุณใช้ผู้ให้บริการด้านความปลอดภัย Java Cryptography Architecture (JCA) รายใด ลองใช้การติดตั้งใช้งานเฟรมเวิร์กที่มีอยู่ในระดับสูงสุดที่รองรับกรณีการใช้งานของคุณ ใช้ผู้ให้บริการที่ Google มีให้ (หากมี) ตามลำดับที่ Google ระบุ

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

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

• ใช้ AES 256 บิตเพื่อวัตถุประสงค์เชิงพาณิชย์ (หากไม่พร้อมใช้งาน ให้ใช้ AES 128 บิต)
• ใช้คีย์สาธารณะขนาด 224 หรือ 256 บิตสําหรับวิทยาการเข้ารหัสลับแบบรูปไข่ (EC)
• ทราบว่าควรใช้โหมดบล็อก CBC, CTR หรือ GCM เมื่อใด
• หลีกเลี่ยงการใช้ IV/ตัวนับซ้ำในโหมด CTR ตรวจสอบว่าคีย์เหล่านี้เป็นแบบสุ่มทางวิทยาการเข้ารหัส
• เมื่อใช้การเข้ารหัส ให้ใช้ความสมบูรณ์โดยใช้โหมด CBC หรือ CTR กับฟังก์ชันใดฟังก์ชันหนึ่งต่อไปนี้
  • HMAC-SHA1
  • HMAC-SHA-256
  • HMAC-SHA-512
  • โหมด GCM

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

หากต้องการจัดเก็บคีย์เพื่อใช้งานซ้ำ ให้ใช้กลไก เช่น KeyStore ที่จัดเก็บและเรียกข้อมูลคีย์การเข้ารหัสในระยะยาว

การสื่อสารระหว่างโปรเซส

แอปบางแอปพยายามใช้ IPC โดยใช้เทคนิคแบบดั้งเดิมของ Linux เช่น โซケットเครือข่ายและไฟล์ที่แชร์ อย่างไรก็ตาม เราขอแนะนำให้คุณใช้ฟังก์ชันการทำงานของระบบ Android สำหรับ IPC เช่น Intent, Binder หรือ Messenger ที่มี Service และ BroadcastReceiver แทน กลไก IPC ของ Android ช่วยให้คุณยืนยันตัวตนของแอปพลิเคชันที่เชื่อมต่อกับ IPC และตั้งค่านโยบายความปลอดภัยสำหรับกลไก IPC แต่ละรายการได้

องค์ประกอบด้านความปลอดภัยหลายอย่างใช้ร่วมกันในกลไก IPC หากกลไก IPC ไม่ได้มีไว้สำหรับแอปพลิเคชันอื่นๆ ให้ตั้งค่าแอตทริบิวต์ android:exported เป็น false ในองค์ประกอบไฟล์ Manifest ของคอมโพเนนต์ เช่น สำหรับองค์ประกอบ <service> ซึ่งมีประโยชน์สําหรับแอปพลิเคชันที่มีกระบวนการหลายรายการภายใน UID เดียวกัน หรือหากคุณตัดสินใจในช่วงท้ายของการพัฒนาว่าไม่ต้องการเปิดเผยฟังก์ชันการทำงานเป็น IPC แต่ก็ไม่ต้องการเขียนโค้ดใหม่

หากแอปพลิเคชันอื่นๆ สามารถเข้าถึง IPC ได้ คุณจะใช้นโยบายความปลอดภัยได้โดยใช้องค์ประกอบ <permission> หาก IPC อยู่ระหว่างแอปที่เป็นของคุณและลงนามด้วยคีย์เดียวกัน ให้ใช้สิทธิ์ signature-level ใน android:protectionLevel

Intent

สำหรับกิจกรรมและ Broadcast Receiver Intent เป็นกลไกที่แนะนำสำหรับ IPC แบบไม่พร้อมกันใน Android คุณอาจใช้ sendBroadcast, sendOrderedBroadcast หรือความตั้งใจที่ชัดเจนกับคอมโพเนนต์แอปพลิเคชันหนึ่งๆ ทั้งนี้ขึ้นอยู่กับข้อกำหนดของแอปพลิเคชัน เราขอแนะนำให้ใช้ Intent ที่ชัดเจนเพื่อความปลอดภัย

ข้อควรระวัง: หากใช้ Intent เพื่อเชื่อมโยงกับ **Service** ให้ใช้ Intent แบบชัดเจนเพื่อรักษาความปลอดภัยให้แอป การใช้ Intent ที่ไม่ชัดแจ้งเพื่อเริ่มบริการเป็นอันตรายต่อความปลอดภัย เนื่องจากคุณไม่สามารถแน่ใจได้ว่าบริการใดจะตอบสนองต่อ Intent และผู้ใช้จะไม่เห็นบริการใดที่เริ่มขึ้น ตั้งแต่ Android 5.0 (API ระดับ 21) เป็นต้นไป ระบบจะแสดงข้อยกเว้นหากคุณเรียกใช้ **bindService()** ด้วย Intent ที่ไม่ชัด

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

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

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

บริการ

Service มักใช้เพื่อจัดหาฟังก์ชันการทำงานให้กับแอปพลิเคชันอื่นๆ คลาสบริการแต่ละคลาสต้องมีการประกาศ <service> ที่สอดคล้องกันในไฟล์ Manifest

โดยค่าเริ่มต้น ระบบจะไม่ส่งออกบริการและแอปพลิเคชันอื่นๆ จะเรียกใช้ไม่ได้ อย่างไรก็ตาม หากคุณเพิ่มตัวกรอง Intent ลงในประกาศบริการ ระบบจะส่งออกตัวกรองดังกล่าวโดยค่าเริ่มต้น คุณควรประกาศแอตทริบิวต์ android:exported อย่างชัดเจนเพื่อให้แน่ใจว่าแอตทริบิวต์จะทํางานตามที่คุณต้องการ นอกจากนี้ คุณยังปกป้องบริการได้โดยใช้แอตทริบิวต์ android:permission เมื่อดำเนินการดังกล่าว แอปพลิเคชันอื่นๆ จะต้องประกาศองค์ประกอบ <uses-permission> ที่เกี่ยวข้องในไฟล์ Manifest ของตนเองจึงจะเริ่มต้น หยุด หรือเชื่อมโยงกับบริการได้

หมายเหตุ: หากแอปกำหนดเป้าหมายเป็น Android 5.0 (API ระดับ 21) ขึ้นไป ให้ใช้ **JobScheduler** เพื่อเรียกใช้บริการที่ทำงานอยู่เบื้องหลัง

บริการสามารถปกป้องการเรียก IPC แต่ละรายการที่ส่งไปยังบริการด้วยสิทธิ์ ซึ่งทำได้โดยการเรียกใช้ checkCallingPermission() ก่อนดำเนินการติดตั้งใช้งานการโทร เราขอแนะนำให้ใช้สิทธิ์แบบประกาศในไฟล์ Manifest เนื่องจากมีแนวโน้มที่จะเกิดการกำกับดูแลน้อยลง

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

อินเทอร์เฟซ Binder และ Messenger

การใช้ Binder หรือ Messenger เป็นกลไกที่แนะนำสำหรับ IPC สไตล์ RPC ใน Android โดยจะมีอินเทอร์เฟซที่กําหนดไว้อย่างชัดเจนซึ่งช่วยให้สามารถตรวจสอบสิทธิ์ปลายทางร่วมกันได้ หากจําเป็น

เราขอแนะนำให้คุณออกแบบอินเทอร์เฟซของแอปในลักษณะที่ไม่จําเป็นต้องตรวจสอบสิทธิ์เฉพาะอินเทอร์เฟซ ระบบไม่ได้ประกาศออบเจ็กต์ Binder และ Messenger ในไฟล์ Manifest ของแอปพลิเคชัน คุณจึงใช้สิทธิ์แบบประกาศกับออบเจ็กต์เหล่านี้โดยตรงไม่ได้ โดยทั่วไปแล้ว ไฟล์เหล่านี้จะรับสิทธิ์ที่ประกาศในไฟล์ Manifest ของแอปพลิเคชันสำหรับ Service หรือ Activity ที่ติดตั้งใช้งาน หากคุณกำลังสร้างอินเทอร์เฟซที่ต้องใช้การตรวจสอบสิทธิ์และ/หรือการควบคุมการเข้าถึง คุณต้องเพิ่มการควบคุมเหล่านั้นเป็นโค้ดในอินเทอร์เฟซ Binder หรือ Messenger อย่างชัดเจน

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

โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ IPC กับบริการที่หัวข้อบริการที่เชื่อมโยง

Broadcast Receiver

BroadcastReceiver จะจัดการคําขอแบบอะซิงโครนัสที่เริ่มต้นโดย Intent

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

ความปลอดภัยด้วยโค้ดที่โหลดแบบไดนามิก

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

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

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

ความปลอดภัยในเครื่องเสมือน

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

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

• การรักษาความปลอดภัยของ Java
• โปรเจ็กต์ที่เกี่ยวข้องของบุคคลที่สาม

เอกสารนี้มุ่งเน้นที่ด้านต่างๆ สำหรับ Android โดยเฉพาะหรือแตกต่างจากสภาพแวดล้อม VM อื่นๆ สําหรับนักพัฒนาซอฟต์แวร์ที่มีประสบการณ์ด้านการเขียนโปรแกรม VM ในสภาพแวดล้อมอื่นๆ ปัญหาหลักๆ 2 ข้อที่อาจแตกต่างออกไปเกี่ยวกับการเขียนแอปสําหรับ Android มีดังนี้

• เครื่องเสมือนบางเครื่อง เช่น JVM หรือรันไทม์ .NET จะทำหน้าที่เป็นขอบเขตความปลอดภัย ซึ่งแยกโค้ดออกจากความสามารถของระบบปฏิบัติการพื้นฐาน ใน Android, Dalvik VM ไม่ใช่ขอบเขตความปลอดภัย ระบบจะใช้แซนด์บ็อกซ์แอปพลิเคชันที่ระดับระบบปฏิบัติการเพื่อให้ Dalvik ทำงานร่วมกับโค้ดเนทีฟในแอปพลิเคชันเดียวกันได้โดยไม่มีข้อจำกัดด้านความปลอดภัย
• เนื่องจากพื้นที่เก็บข้อมูลในอุปกรณ์เคลื่อนที่มีจำกัด นักพัฒนาแอปจึงต้องการสร้างแอปพลิเคชันแบบโมดูลและใช้การโหลดคลาสแบบไดนามิกเป็นปกติ เมื่อดำเนินการนี้ ให้พิจารณาทั้งแหล่งที่มาที่คุณดึงข้อมูลตรรกะแอปพลิเคชันและที่เก็บข้อมูลไว้ในเครื่อง อย่าใช้การโหลดคลาสแบบไดนามิกจากแหล่งที่มาที่ไม่ได้รับการยืนยัน เช่น แหล่งที่มาของเครือข่ายที่ไม่ปลอดภัยหรือพื้นที่เก็บข้อมูลภายนอก เนื่องจากโค้ดดังกล่าวอาจมีการแก้ไขให้มีพฤติกรรมที่เป็นอันตราย

ความปลอดภัยในโค้ดเนทีฟ

โดยทั่วไป เราขอแนะนำให้ใช้ Android SDK สำหรับการพัฒนาแอปพลิเคชัน แทนที่จะใช้โค้ดเนทีฟกับ Android NDK แอปพลิเคชันที่สร้างขึ้นด้วยโค้ดเนทีฟมีความซับซ้อนกว่า ย้ายข้อมูลได้ยากกว่า และมีโอกาสที่จะมีข้อผิดพลาดที่พบได้ทั่วไปเกี่ยวกับหน่วยความจำที่เสียหาย เช่น บัฟเฟอร์ล้น

Android สร้างขึ้นโดยใช้เคอร์เนล Linux และการคุ้นเคยกับแนวทางปฏิบัติแนะนำด้านความปลอดภัยในการพัฒนาด้วย Linux จะมีประโยชน์อย่างยิ่งหากคุณใช้โค้ดเนทีฟ แนวทางปฏิบัติด้านความปลอดภัยของ Linux อยู่นอกเหนือขอบเขตของเอกสารนี้ แต่แหล่งข้อมูลยอดนิยมแหล่งหนึ่งคือ Secure Programming HOWTO - Creating Secure Software

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