หมวดหมู่ OWASP: MASVS-CODE: คุณภาพโค้ด
ภาพรวม
แอปพลิเคชัน Android ใช้ประโยชน์จากโค้ดแบบเนทีฟที่เขียนด้วยภาษาต่างๆ เช่น C และ C++ สำหรับฟังก์ชันการทำงานบางอย่างได้ อย่างไรก็ตาม เมื่อแอปพลิเคชันใช้ Java Native Interface (JNI) เพื่อโต้ตอบกับโค้ดแบบเนทีฟนี้ อาจทำให้มีช่องโหว่ เช่น บัฟเฟอร์ล้นและปัญหาอื่นๆ ที่อาจพบในการใช้งานโค้ดแบบเนทีฟ
ผลกระทบ
แม้จะให้ผลกระทบในเชิงบวก เช่น การเพิ่มประสิทธิภาพประสิทธิภาพและการสร้างความสับสน แต่การใช้โค้ดแบบเนทีฟในแอปพลิเคชัน Android อาจทำให้เกิดผลกระทบด้านความปลอดภัยได้ ภาษาโค้ดเนทีฟอย่าง C/C++ ไม่มีฟีเจอร์ด้านความปลอดภัยของหน่วยความจำอย่าง Java/Kotlin ทำให้เสี่ยงต่อช่องโหว่ต่างๆ เช่น บัฟเฟอร์ล้น ข้อผิดพลาดการใช้งานหลังช่วงใช้ฟรี และปัญหาความเสียหายของหน่วยความจำอื่นๆ ซึ่งนำไปสู่การขัดข้องหรือการดำเนินการโค้ดแบบสุ่ม นอกจากนี้ หากคอมโพเนนต์โค้ดเนทีฟมีช่องโหว่ ก็อาจทำให้แอปพลิเคชันทั้งแอปถูกบุกรุกได้ แม้ว่าส่วนที่เหลือจะเขียนด้วย Java อย่างปลอดภัยก็ตาม
การลดปัญหา
คำแนะนำเกี่ยวกับการพัฒนาและการเขียนโค้ด
- หลักเกณฑ์การเขียนโค้ดที่ปลอดภัย: สำหรับโปรเจ็กต์ C/C++ ให้ปฏิบัติตามมาตรฐานการเขียนโค้ดที่ปลอดภัยที่กำหนดไว้ (เช่น CERT, OWASP) เพื่อลดช่องโหว่ เช่น การเขียนข้อมูลไปยังบัฟเฟอร์มากเกินไป การเขียนข้อมูลไปยังจำนวนเต็มมากเกินไป และการโจมตีสตริงการจัดรูปแบบ ให้ความสำคัญกับไลบรารี อย่าง Abseil ที่ขึ้นชื่อเรื่องคุณภาพและความปลอดภัย เมื่อเป็นไปได้ ให้พิจารณาใช้ภาษาที่ปลอดภัยต่อหน่วยความจำ เช่น Rust ซึ่งมีประสิทธิภาพเทียบเท่ากับ C/C++
- การตรวจสอบอินพุต: ตรวจสอบข้อมูลอินพุตทั้งหมดที่ได้รับจากแหล่งที่มาภายนอกอย่างเข้มงวด รวมถึงข้อมูลจากผู้ใช้ ข้อมูลเครือข่าย และไฟล์ต่างๆ เพื่อป้องกันการโจมตีด้วยการแทรกและช่องโหว่อื่นๆ
เพิ่มความเข้มงวดให้กับตัวเลือกการคอมไพล์
ไลบรารีแบบเนทีฟที่ใช้รูปแบบ ELF สามารถเสริมการป้องกันช่องโหว่ต่างๆ ได้ด้วยการเปิดใช้งานกลไกป้องกัน เช่น สแต็กการป้องกัน (Canary), การย้ายข้อมูลแบบอ่านอย่างเดียว (RELRO), การป้องกันการดำเนินการข้อมูล (NX) และไฟล์ปฏิบัติการที่ไม่ขึ้นอยู่กับตำแหน่ง (PIE) ซึ่งเป็นตัวเลือกที่สะดวก ตัวเลือกการรวบรวม Android NDK เปิดใช้การป้องกันเหล่านี้ทั้งหมดโดยค่าเริ่มต้นอยู่แล้ว
หากต้องการยืนยันการใช้กลไกความปลอดภัยเหล่านี้ภายในไบนารี คุณสามารถใช้เครื่องมืออย่าง hardening-check
หรือ pwntools
Bash
$ pwn checksec --file path/to/libnativecode.so
Arch: aarch64-64-little
RELRO: Full RELRO
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
ตรวจสอบว่าไลบรารีของบุคคลที่สามไม่มีช่องโหว่
เมื่อเลือกไลบรารีของบุคคลที่สาม ให้ให้ความสำคัญกับไลบรารีที่มีชื่อเสียงดีในชุมชนนักพัฒนาซอฟต์แวร์ แหล่งข้อมูลอย่างดัชนี SDK ของ Google Play ช่วยคุณระบุไลบรารีที่ได้รับการยอมรับและน่าเชื่อถือ อย่าลืมอัปเดตไลบรารีเป็นเวอร์ชันล่าสุดอยู่เสมอ และค้นหาช่องโหว่ที่ทราบซึ่งเกี่ยวข้องกับไลบรารีเหล่านั้นในเชิงรุกโดยใช้ทรัพยากร เช่น ฐานข้อมูลจาก Exploit-DB การค้นเว็บโดยใช้คีย์เวิร์ด เช่น [library_name] vulnerability
หรือ [library_name] CVE
อาจเปิดเผยข้อมูลความปลอดภัยที่สำคัญได้
แหล่งข้อมูล
- CWE-111: การใช้ JNI ที่ไม่เป็นอันตรายโดยตรง
- ฐานข้อมูลช่องโหว่
- ตรวจสอบไบนารีเพื่อหาฟีเจอร์การรักษาความปลอดภัย
- ตรวจสอบการตั้งค่าความปลอดภัยของไบนารีด้วย pwntools
- การปิดช่องโหว่ความปลอดภัยในไบนารีของ Linux
- การทำให้ไบนารี ELF แข็งแกร่งขึ้นโดยใช้การย้ายข้อมูลแบบอ่านอย่างเดียว (RELRO)
- กลไกการป้องกันไบนารีของ OWASP
- มาตรฐานการเขียนโค้ดของ SEI CERT
- คู่มือนักพัฒนาซอฟต์แวร์ OWASP
- ดัชนี SDK ของ Google Play
- Android NDK
- ข้อมูลเบื้องต้นเกี่ยวกับ Rust สำหรับ Android
- Abseil (คลัง C++ ทั่วไป)
- Linker จะบังคับใช้ PIE