Verwendung von nativem Code

OWASP-Kategorie:MASVS-CODE: Code Quality

Übersicht

Android-Anwendungen können für bestimmte Funktionen nativen Code nutzen, der in Sprachen wie C und C++ geschrieben wurde. Wenn eine Anwendung jedoch das Java Native Interface (JNI) verwendet, um mit diesem nativen Code zu interagieren, ist sie möglicherweise anfällig für Sicherheitslücken wie Pufferüberläufe und andere Probleme, die in der Implementierung des nativen Codes vorhanden sein können.

Auswirkungen

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++ haben nicht die Arbeitsspeichersicherheitsfunktionen von Java/Kotlin, wodurch sie anfällig für Sicherheitslücken wie Überläufe des Zwischenspeichers, Use-After-Free-Fehler und andere Probleme mit der Arbeitsspeicherbeschädigung sind, die zu Abstürzen oder zur Ausführung von beliebigem Code führen können. Wenn eine Sicherheitslücke in der nativen Codekomponente vorhanden ist, kann sie außerdem die gesamte Anwendung gefährden, auch wenn der Rest sicher in Java geschrieben ist.

Gegenmaßnahmen

Hinweise zur Entwicklung und zum Programmieren

  • Richtlinien für sicheres Programmieren: Halten Sie sich bei C/C++-Projekten an etablierte Standards für sicheres Programmieren (z.B. CERT, OWASP), um Sicherheitslücken wie Pufferüberläufe, Ganzzahlüberläufe und Formatstring-Angriffe zu vermeiden. Priorisieren Sie Bibliotheken wie Abseil, die für Qualität und Sicherheit bekannt sind. Erwägen Sie nach Möglichkeit die Verwendung speichersicherer Sprachen wie Rust, die eine mit C/C++ vergleichbare Leistung bieten.
  • Eingabevalidierung: Validieren Sie alle Eingabedaten, die von externen Quellen empfangen werden, einschließlich Nutzereingaben, Netzwerkdaten und Dateien, um Injection-Angriffe und andere Sicherheitslücken zu verhindern.

Kompilierungsoptionen härten

Native Bibliotheken, die das ELF-Format verwenden, können durch Aktivieren von Schutzmechanismen wie Stack-Schutz (Canary), Relocation Read-Only (RELRO), Data Execution Prevention (NX) und Position-Independent Executables (PIE) vor einer Reihe von Sicherheitslücken geschützt werden. Praktischerweise sind alle diese Schutzmaßnahmen in den Android NDK-Kompilierungsoptionen standardmäßig aktiviert.

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 anfällig sind

Achten Sie bei der Auswahl von Drittanbieterbibliotheken darauf, dass sie in der Entwicklercommunity einen guten Ruf haben. Ressourcen wie der Google Play SDK Index können Ihnen dabei helfen, angesehene und vertrauenswürdige Bibliotheken zu finden. Achten Sie darauf, dass die Bibliotheken auf dem neuesten Stand sind, und suchen Sie proaktiv nach bekannten Sicherheitslücken, die mit ihnen zusammenhängen, indem Sie Ressourcen wie die Datenbanken von Exploit-DB verwenden. Eine Websuche mit Keywords wie [library_name] vulnerability oder [library_name] CVE kann wichtige Sicherheitsinformationen liefern.

Ressourcen