Die Sicherheit mobiler Anwendungen leidet oft unter einem falschen Sicherheitsgefühl, das durch Standard-Build-Tools vermittelt wird. Im React Native-Ökosystem gehen viele Entwickler davon aus, dass die Verschleierung durch Hermes-Bytecode eine wirksame Barriere gegen Reverse Engineering darstellt.
Aktuelle Untersuchungen zeigen, dass diese Annahme falsch ist. In einem autorisierten Test konnte ein produktives API-Authentifizierungsschema rekonstruiert werden, ohne jemals das JavaScript-Bundle dekompilieren zu müssen. Der Angriff konzentrierte sich auf die JavaScript-zu-Native-Bridge und bewies, dass die eigentliche Sicherheitsgrenze darin liegt, wie die App mit Daten und Anmeldeinformationen umgeht, und nicht in der Verschleierung des Quellcodes.
Kurz gesagt
- •
Hermes-Bytecode bietet keinen wirksamen Schutz gegen Reverse Engineering; gehen Sie davon aus, dass die gesamte clientseitige Logik für Angreifer sichtbar ist.
- •
Die JavaScript-zu-Native-Bridge ist die primäre Angriffsfläche, an der Anforderungsabläufe und sensible Anmeldeinformationen am anfälligsten für Abgriffe sind.
- •
Härtungsmaßnahmen sollten sich darauf konzentrieren, den Schadensradius eines kompromittierten Clients zu minimieren, anstatt zu versuchen, die Anwendung unknackbar zu machen.
Der Mythos der Verschleierung
Der häufigste Fehler bei der Sicherheit von React Native ist der Glaube, dass der Build-Prozess die Geschäftslogik verbirgt. Obwohl Hermes-Bytecode die statische Analyse erschwert, verhindert er nicht, dass ein Angreifer das Anwendungsverhalten zur Laufzeit beobachtet.
Angreifer müssen Ihren Code nicht dekompilieren, wenn sie einfach den Datenverkehr über die Bridge beobachten können. Durch das Erfassen der Request-Flows an der Bridge können sie die API-Struktur rekonstruieren und die genauen Anmeldeinformationen für die Authentifizierung identifizieren. Sobald die API abgebildet ist, wird die Anwendungslogik für den Angreifer irrelevant.
Absicherung der Bridge
Die Verteidigung einer React Native-Anwendung erfordert die Akzeptanz, dass der Client von Natur aus nicht vertrauenswürdig ist. Da Benutzer die Hardware kontrollieren, kann jeder Code, der auf diesem Gerät ausgeführt wird, analysiert oder manipuliert werden.
Anstatt sich auf das Verstecken von Code zu konzentrieren, sollten Architekten die Auswirkungen eines kompromittierten Clients begrenzen. Dies beinhaltet die Implementierung einer robusten serverseitigen Validierung, die Sicherstellung, dass API-Schlüssel oder Token nicht einfach aus dem lokalen Speicher abrufbar sind, und die Behandlung aller Daten, die vom mobilen Client kommen, als potenziell bösartig. Wenn es einem Angreifer gelingt, Ihre API-Aufrufe zu rekonstruieren, muss der Server in der Lage sein, unbefugte Zugriffsmuster zu erkennen und zu blockieren.
Bei der Sicherheit in React Native geht es nicht darum, Ihre App unknackbar zu machen. Es geht darum, den Analyseaufwand für Angreifer zu erhöhen und sicherzustellen, dass Ihre Backend-Infrastruktur auch dann resilient bleibt, wenn die clientseitige Implementierung vollständig offengelegt ist.
Quelle
Hardening React Native Apps: What the JS Bridge Exposes and How to Defend It | IQCrafter Insights
https://iqcrafter.com/blog/securing-react-native-apps-against-reverse-engineering
