Использование собственного кода

Категория 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 .

Баш 

$ 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 Index, помогут вам определить заслуживающие доверия и уважаемые библиотеки. Убедитесь, что библиотеки обновлены до последних версий, и активно ищите известные уязвимости, связанные с ними, используя такие ресурсы, как базы данных Exploit-DB . Веб-поиск по ключевым словам, таким как [library_name] vulnerability или [library_name] CVE может выявить важную информацию о безопасности.

Ресурсы