Danh mục OWASP: MASVS-CODE: Chất lượng mã
Tổng quan
Các ứng dụng Android có thể tận dụng mã gốc được viết bằng các ngôn ngữ như C và C++ cho các chức năng cụ thể. Tuy nhiên, khi một ứng dụng sử dụng Giao diện gốc Java (JNI) để tương tác với mã gốc này, ứng dụng đó có thể bị lộ các lỗ hổng như tràn bộ đệm và các vấn đề khác có thể xuất hiện trong quá trình triển khai mã gốc.
Tác động
Mặc dù có những tác động rất tích cực như tối ưu hoá hiệu suất và làm rối mã nguồn, nhưng việc sử dụng mã gốc trong các ứng dụng Android có thể gây ra những tác động tiêu cực đến bảo mật. Các ngôn ngữ mã gốc như C/C++ thiếu các tính năng an toàn về bộ nhớ của Java/Kotlin, khiến chúng dễ bị các lỗ hổng như tràn bộ đệm, lỗi use-after-free và các vấn đề hỏng bộ nhớ khác – dẫn đến sự cố hoặc thực thi mã tuỳ ý. Ngoài ra, nếu có lỗ hổng trong thành phần mã gốc, thì lỗ hổng đó có thể làm hỏng toàn bộ ứng dụng, ngay cả khi phần còn lại được viết một cách an toàn bằng Java.
Giải pháp giảm thiểu
Hướng dẫn phát triển và lập trình
- Nguyên tắc lập trình an toàn: Đối với các dự án C/C++, hãy tuân thủ các tiêu chuẩn lập trình an toàn đã thiết lập (ví dụ: CERT, OWASP) để giảm thiểu các lỗ hổng như tràn bộ đệm, tràn số nguyên và các cuộc tấn công chuỗi định dạng. Ưu tiên các thư viện như Abseil nổi tiếng về chất lượng và bảo mật. Bất cứ khi nào có thể, hãy cân nhắc việc sử dụng các ngôn ngữ an toàn đối với bộ nhớ như Rust. Ngôn ngữ này mang lại hiệu suất tương đương với C/C++.
- Xác thực dữ liệu đầu vào: Xác thực nghiêm ngặt tất cả dữ liệu đầu vào nhận được từ các nguồn bên ngoài, bao gồm cả dữ liệu đầu vào của người dùng, dữ liệu mạng và tệp để ngăn chặn các cuộc tấn công chèn và các lỗ hổng khác.
Tăng cường các lựa chọn biên dịch
Bạn có thể tăng cường bảo mật cho các thư viện gốc sử dụng định dạng ELF trước một loạt các lỗ hổng bằng cách kích hoạt các cơ chế bảo vệ như bảo vệ ngăn xếp (Canary), chỉ có thể đọc khi di chuyển (RELRO), ngăn chặn thực thi dữ liệu (NX) và tệp thực thi độc lập với vị trí (PIE). Rất thuận tiện khi các tuỳ chọn biên dịch Android NDK đã bật tất cả các biện pháp bảo vệ này theo mặc định.
Để xác minh việc triển khai các cơ chế bảo mật này trong tệp nhị phân, bạn có thể sử dụng các công cụ như hardening-check
hoặc 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
Xác minh thư viện bên thứ ba không bị lỗ hổng
Khi chọn thư viện bên thứ ba, hãy ưu tiên sử dụng những thư viện có uy tín vững chắc trong cộng đồng phát triển. Các tài nguyên như Chỉ mục SDK của Google Play có thể giúp bạn xác định các thư viện có uy tín và đáng tin cậy. Đảm bảo bạn luôn cập nhật thư viện lên phiên bản mới nhất và chủ động tìm kiếm mọi lỗ hổng đã biết liên quan đến thư viện bằng các tài nguyên như cơ sở dữ liệu của Exploit-DB. Việc tìm kiếm trên web bằng các từ khoá như [library_name] vulnerability
hoặc [library_name] CVE
có thể tiết lộ thông tin bảo mật quan trọng.
Tài nguyên
- CWE-111: Sử dụng trực tiếp JNI không an toàn
- Cơ sở dữ liệu khai thác
- Kiểm tra tệp nhị phân để tìm các tính năng tăng cường bảo mật
- Kiểm tra chế độ cài đặt bảo mật nhị phân bằng pwntools
- Tăng cường bảo mật nhị phân của Linux
- Củng cố tệp nhị phân ELF bằng tính năng Chỉ có thể đọc khi di chuyển (RELRO)
- Cơ chế bảo vệ tệp nhị phân của OWASP
- Tiêu chuẩn lập trình SEI CERT
- Hướng dẫn dành cho nhà phát triển OWASP
- Chỉ mục SDK của Google Play
- Android NDK
- Giới thiệu về Rust cho Android
- Abseil (Thư viện chung C++)
- Trình liên kết thực thi PIE