OWASP-Kategorie: MASVS-CODE: Codequalität
Übersicht
Android-Anwendungen können für bestimmte Funktionen nativen Code verwenden, der in Sprachen wie C und C++ geschrieben wurde. Wenn eine Anwendung jedoch das Java Native Interface (JNI) für die Interaktion mit diesem nativen Code verwendet, birgt sie möglicherweise Sicherheitslücken wie Pufferüberläufe und andere Probleme, die in der nativen Codeimplementierung bestehen können.
Positiv beeinflussen
Trotz sehr positiver Auswirkungen wie Leistungsoptimierung und Verschleierung kann die Verwendung von nativem Code in Android-Anwendungen negative Auswirkungen auf die Sicherheit haben. Native Codesprachen wie C/C++ bieten nicht die Speichersicherheitsfunktionen von Java/Kotlin. Daher sind sie anfällig für Sicherheitslücken wie Pufferüberläufe, Use-After-Free-Fehler und andere Probleme mit Arbeitsspeicherbeschädigungen, die zu Abstürzen oder der Ausführung beliebigen Codes führen können. Wenn in der nativen Codekomponente eine Sicherheitslücke vorhanden ist, kann dies auch die gesamte Anwendung gefährden, auch wenn der Rest sicher in Java geschrieben ist.
Abhilfemaßnahmen
Hinweise zur Entwicklung und Programmierung
- Richtlinien für sicheres Coding: Halten Sie für C/C++-Projekte etablierte sichere Programmierstandards wie CERT, OWASP) zur Behebung von Sicherheitslücken wie Puffer- und Ganzzahl-Overflows und Formatstring-Angriffen. Priorisieren Sie Bibliotheken wie Abseil, die für Qualität und Sicherheit bekannt sind. Verwenden Sie nach Möglichkeit speichersichere Sprachen wie Rust, die eine Leistung bieten, die mit C/C++ vergleichbar ist.
- Eingabevalidierung: Validieren Sie alle von externen Quellen empfangenen Eingabedaten, einschließlich Nutzereingaben, Netzwerkdaten und Dateien, gründlich, um Injection-Angriffe und andere Sicherheitslücken zu verhindern.
Kompilierungsoptionen verschärfen
Native Bibliotheken, die das ELF-Format verwenden, können durch Aktivierung von Schutzmechanismen wie Stack-Schutz (Canary), Read-Only-Relocation (RELRO), Data Execution Prevention (NX) und Positionsunabhängige ausführbare Dateien (PIE) gegen eine Reihe von Sicherheitslücken geschützt werden. Praktischerweise aktivieren die Android-NDK-Kompilierungsoptionen alle diese Schutzmaßnahmen bereits standardmäßig.
Um die Implementierung dieser Sicherheitsmechanismen in einem Binärprogramm zu überprüfen, können Sie Tools wie hardening-check
oder pwntools
verwenden.
Bash
$ pwn checksec --file path/to/libnativecode.so
Arch: aarch64-64-little
RELRO: Full RELRO
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
Prüfen, ob Drittanbieterbibliotheken nicht angreifbar sind
Wählen Sie bei der Auswahl von Drittanbieterbibliotheken solche mit einem guten Ruf in der Entwicklungscommunity aus. Ressourcen wie der Google Play SDK-Index können dir dabei helfen, angesehene und vertrauenswürdige Bibliotheken zu identifizieren. Achten Sie darauf, dass die Bibliotheken immer auf dem neuesten Stand sind, und suchen Sie proaktiv mithilfe von Ressourcen wie den Datenbanken von Exploit-DB nach bekannten Sicherheitslücken. Eine Websuche mit Keywords wie [library_name] vulnerability
oder [library_name] CVE
kann wichtige Sicherheitsinformationen offenlegen.
Ressourcen
- CWE-111: Direkte Verwendung unsicherer JNI
- Exploit-Datenbank
- Binärdateien auf Funktionen zur Sicherheitshärtung prüfen
- Binäre Sicherheitseinstellungen mit pwntools prüfen
- Härtung der Sicherheit von Linux-Binärdateien
- ELF-Binärprogramme mit Relocation Read-Only (RELRO) härten
- OWASP-Mechanismen zum Binärschutz
- SEI CERT-Codierungsstandards
- OWASP-Entwicklerleitfaden
- Google Play SDK Index
- Android NDK
- Einführung in Android Rust
- Abseil (C++ Common Libraries)
- PIE wird vom Linker erzwungen