Категория OWASP: MASVS-CODE: Качество кода
Обзор
Приложения Android могут использовать собственный код, написанный на таких языках, как C и C++, для выполнения определенных функций. Однако когда приложение использует собственный интерфейс Java (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
.
Баш
$ pwn checksec --file path/to/libnativecode.so
Arch: aarch64-64-little
RELRO: Full RELRO
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
Убедитесь, что сторонние библиотеки не уязвимы
При выборе сторонних библиотек отдавайте предпочтение библиотекам с солидной репутацией в сообществе разработчиков. Такие ресурсы, как индекс Google Play SDK, могут помочь вам определить уважаемые и заслуживающие доверия библиотеки. Обязательно обновляйте библиотеки до последних версий и активно ищите любые известные уязвимости, связанные с ними, используя такие ресурсы, как базы данных из Exploit-DB . Поиск в Интернете с использованием таких ключевых слов, как [library_name] vulnerability
или [library_name] CVE
может выявить важную информацию о безопасности.
Ресурсы
- CWE-111: Прямое использование небезопасного JNI
- Эксплойт базы данных
- Проверьте двоичные файлы на наличие функций усилен��я безопасности.
- Проверьте настройки двоичной безопасности с помощью pwntools
- Усиление двоичной безопасности Linux
- Усиление защиты двоичных файлов ELF с помощью перемещения только для чтения (RELRO)
- Механизмы двоичной защиты OWASP
- Стандарты кодирования SEI CERT
- Руководство разработчика OWASP
- Индекс Google Play SDK
- Android НДК
- Введение в Android Rust
- Abseil (общие библиотеки C++)
- PIE обеспечивается компоновщиком