Korzystanie z kodu natywnego
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Kategoria OWASP: MASVS-CODE: jakość kodu
Omówienie
Aplikacje na Androida mogą wykorzystywać kod natywny napisany w językach takich jak C i C++, by obsługiwać określone funkcje. Jednak gdy aplikacja używa natywnego interfejsu Java (JNI) do interakcji z tym kodem natywnym, może być narażona na luki w zabezpieczeniach, takie jak przepełnienia bufora i inne problemy, które mogą występować w implementacji kodu natywnego.
Wpływ
Pomimo bardzo pozytywnych skutków, takich jak optymalizacja wydajności i zaciemnianie, korzystanie z kodu natywnego w aplikacjach na Androida może mieć negatywny wpływ na bezpieczeństwo. Języki kodu natywnego, takie jak C/C++, nie mają funkcji bezpieczeństwa pamięci, które są dostępne w przypadku Java/Kotlin, przez co są podatne na luki w zabezpieczeniach, takie jak przepełnienia bufora, błędy use-after-free i inne problemy z uszkodzoną pamięcią, które mogą prowadzić do awarii lub niekontrolowanego wykonania kodu. Poza tym jeśli w komponencie kodu natywnego znajduje się luka, może ona potencjalnie zagrażać bezpieczeństwu całej aplikacji, nawet jeśli pozostała część jest zapisana w bezpieczny sposób w języku Java.
Łagodzenie
Wskazówki dotyczące programowania i kodowania
- Wytyczne dotyczące bezpiecznego kodowania: w przypadku projektów w językach C/C++ należy przestrzegać ustalonych standardów bezpiecznego kodowania (np. CERT, OWASP) w celu zminimalizowania luk w zabezpieczeniach, takich jak przepełnienie bufora, przepełnienie liczby całkowitej i ataki na formatowanie ciągu znaków. Ustaw priorytety dla bibliotek, takich jak Abseil, które są znane z jakości i bezpieczeństwa. W miarę możliwości staraj się wdrażać języki bezpieczne w pamięci, takie jak Rust. Wydajność ta jest porównywalna z językiem C/C++.
- Weryfikacja danych wejściowych: rygorystyczna weryfikacja wszystkich danych wejściowych otrzymywanych ze źródeł zewnętrznych, w tym danych wejściowych użytkownika, danych sieciowych i plików, w celu zapobiegania atakom polegającym na wstrzykiwaniu kodu i innym podatnościom.
Zaostrzenie opcji kompilacji
Biblioteki natywne korzystające z formatu ELF mogą być zabezpieczone przed różnymi podatnościami poprzez włączenie mechanizmów ochronnych, takich jak ochrona stosu (Canary), przeniesienie tylko do odczytu (RELRO), zapobieganie wykonywaniu danych (NX) i pliki wykonywalne niezależne od pozycji (PIE). Dla wygody opcje kompilacji Androida NDK
są już domyślnie włączone dla wszystkich tych zabezpieczeń.
Aby sprawdzić implementację tych mechanizmów zabezpieczeń w plikach binarnych, możesz użyć narzędzi takich jak hardening-check lub 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
Sprawdź, czy biblioteki innych firm nie są podatne na ataki
Wybierając biblioteki innych firm, stawiaj na te, które mają dobrą reputację w społeczności programistów. Materiały takie jak indeks pakietów SDK Google Play mogą pomóc Ci znaleźć godne zaufania biblioteki. Zadbaj o to, aby biblioteki były zawsze aktualizowane do najnowszych wersji, i proaktywnie szukaj znanych luk związanych z nimi, korzystając z zasobów takich jak bazy danych Exploit-DB. Wyszukiwanie w internecie przy użyciu słów kluczowych takich jak [library_name] vulnerability lub [library_name] CVE może ujawnić kluczowe informacje dotyczące bezpieczeństwa.
Materiały
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-26 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 2025-07-26 UTC."],[],[],null,["# Use of native code\n\n\u003cbr /\u003e\n\n**OWASP category:** [MASVS-CODE: Code Quality](https://mas.owasp.org/MASVS/10-MASVS-CODE)\n\nOverview\n--------\n\nAndroid applications can take advantage of native code written in languages like\nC and C++ for specific functionalities. However, when an application utilizes\nthe Java Native Interface (JNI) to interact with this native code, it\npotentially exposes itself to vulnerabilities like buffer overflows and other\nissues that may be present in the native code implementation.\n\nImpact\n------\n\nDespite very positive impacts such as performance optimization and obfuscation,\nutilizing native code in Android applications can have negative security\nimpacts. Native code languages like C/C++ lack the memory safety features of\nJava/Kotlin, making them susceptible to vulnerabilities like buffer overflows,\nuse-after-free errors, and other memory corruption issues -- leading to crashes\nor arbitrary code execution. Additionally, if a vulnerability exists in the\nnative code component, it can potentially compromise the entire application,\neven if the rest is written securely in Java.\n\nMitigations\n-----------\n\n### Development and coding guidance\n\n- **Secure Coding Guidelines**: For C/C++ projects, adhere to established secure coding standards (e.g., CERT, OWASP) to mitigate vulnerabilities like buffer overflows, integer overflows, and format string attacks. Prioritize libraries like Abseil known for quality and security. Whenever possible, consider adopting memory-safe languages like Rust, which offer performance comparable to C/C++.\n- **Input Validation**: Rigorously validate all input data received from external sources, including user input, network data, and files, to prevent injection attacks and other vulnerabilities.\n\n### Harden the compilation options\n\nNative libraries utilizing the ELF format can be hardened against a range of\nvulnerabilities by activating protective mechanisms like stack protection\n(Canary), relocation read-only (RELRO), data execution prevention (NX), and\nposition-independent executables (PIE). Conveniently, the Android NDK\ncompilation options already enable all these protections by default.\n\nTo verify the implementation of these security mechanisms within a binary, you\ncan employ tools like `hardening-check` or `pwntools`. \n\n### Bash\n\n $ pwn checksec --file path/to/libnativecode.so\n Arch: aarch64-64-little\n RELRO: Full RELRO\n Stack: Canary found\n NX: NX enabled\n PIE: PIE enabled\n\n### Verify third-party libraries are not vulnerable\n\nWhen choosing third-party libraries, prioritize using those with a solid\nreputation in the development community. Resources like the [Google Play SDK\nIndex](https://play.google.com/sdks) can help you identify well-regarded and trustworthy libraries. Ensure\nyou keep the libraries updated to the latest versions and proactively search for\nany known vulnerabilities related to them using resources like the databases\nfrom [Exploit-DB](https://www.exploit-db.com/). A web search using keywords like\n`[library_name] vulnerability` or `[library_name] CVE` can reveal critical\nsecurity information.\n\nResources\n---------\n\n- [CWE-111: Direct Use of Unsafe JNI](https://cwe.mitre.org/data/definitions/111.html)\n- [Exploit database](https://www.exploit-db.com/)\n- [Check binaries for security hardening features](https://www.systutorials.com/docs/linux/man/1-hardening-check/)\n- [Check binary security settings with pwntools](https://docs.pwntools.com/en/stable/commandline.html#pwn-checksec)\n- [Linux binary security hardening](https://medium.com/@n80fr1n60/linux-binary-security-hardening-1434e89a2525)\n- [Hardening ELF binaries using Relocation Read-Only (RELRO)](https://www.redhat.com/fr/blog/hardening-elf-binaries-using-relocation-read-only-relro)\n- [OWASP binary protection mechanisms](https://mas.owasp.org/MASTG/Android/0x05i-Testing-Code-Quality-and-Build-Settings/#binary-protection-mechanisms)\n- [SEI CERT Coding Standards](https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards)\n- [OWASP Developer Guide](https://owasp.org/www-project-developer-guide/release/)\n- [Google Play SDK Index](https://play.google.com/sdks)\n- [Android NDK](/ndk)\n- [Android Rust introduction](https://source.android.com/docs/setup/build/rust/building-rust-modules/overview)\n- [Abseil (C++ Common Libraries)](https://github.com/abseil/abseil-cpp)\n- [PIE is enforced by the linker](https://cs.android.com/android/platform/superproject/main/+/main:bionic/linker/linker_main.cpp;l=425?q=linker_main&ss=android%2Fplatform%2Fsuperproject%2Fmain)"]]
