Категория 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: Direct Use of Unsafe JNI
- База данных эксплойтов
- Проверка двоичных файлов на наличие функций усиления защиты
- Проверка настроек безопасности двоичных файлов с помощью pwntools
- Укрепление защиты двоичных файлов Linux
- Усиление защиты двоичных файлов ELF с помощью RELRO
- Механизмы защиты двоичного кода OWASP
- Стандарты кодирования SEI CERT
- Руководство для разработчиков OWASP
- Google Play SDK Index
- Android NDK
- Введение в Rust для Android
- Abseil (общие библиотеки C++)
- PIE применяется связывателем