Cross-Plattform-Entwicklung – wie sicher ist die Entwicklung für unterschiedliche Systeme?
Kommentare

Cross-Plattform-Entwicklung – das ergibt ein Programm, das auf mehreren völlig unterschiedlichen Systemen läuft. Dies führt doch zwangsweise zu Kompromissen, unter denen am Ende die Sicherheit des Programms leidet, oder?

Oder sind die so entwickelten Programme vielleicht ganz besonders sicher, da sie auf Frameworks etc. angewiesen sind, die sich ganz nebenbei auch um die Sicherheitsprobleme kümmern? Oder liegt die Wahrheit irgendwo in der Mitte? Auf jeden Fall interessieren sich Sicherheitsforscher schon seit einiger Zeit für die Cross-Plattform-Entwicklung. Und das würden sie nicht tun, wenn es da nichts zu entdecken gäbe. Ganz so gut scheint es mit der Sicherheit also nicht zu stehen, denn mit einem Vortrag nach dem Muster  „Guten Morgen, mein Name ist Whitehat Hackerhase. Mein Thema heute ist die Sicherheit der Cross-Plattform-Entwicklung. Machen wir es kurz: Hier gibt es nichts zu sehen, die Frameworks und die damit erstellten Apps sind alle sicher. Bitte gehen Sie weiter, das Buffet im Nebenraum ist eröffnet. Vielen Dank!“ lässt sich kein Advisory Board hinter dem Ofen hervorlocken. Also sehen wir uns einmal an, was die Sicherheitsforscher herausgefunden haben.

Cross-Plattform-Apps – Traum oder Albtraum?

Auf der Black Hat Asia 2015 haben die zwei Sicherheitsforscher Marco Grassi und Sebastián Guerrero einen Vortrag mit dem Titel „The Nightmare Behind the Cross Platform Mobile Apps Dream“ gehalten. Sie haben die für die Cross-Plattform-Entwicklung populärsten verwendeten Frameworks auf Sicherheitsaspekte analysiert und eine Reihe von Schwachstellen und Angriffspunkten gefunden. Und auch Simon Roses Femerling hat sich mit der Sicherheit von Cross-Plattform-Technologien beschäftigt. Sein Vortrag auf der Black Hat Asia 2014 hatte den Titel „The Inner Workings of Mobile Cross-Platform Technologies“.

Ich habe die Ergebnisse beider Vorträge im Folgenden zusammengefasst. Im Wesentlichen ging es in den Vorträgen um die Beantwortung einiger wichtiger Fragen:

  • Wie gut ist die Codequalität der Frameworks?
  • Entstehen durch ihre Verwendung Schwachstellen?
  • Betreffen solche Schwachstellen alle Apps, die das gleiche Framework verwenden?
  • Wie leicht kann ein Angreifer die Apps analysieren und manipulieren?

Die untersuchten Frameworks

Marco Grassi und Sebastián Guerrero sowie Simon Roses Femerling haben teilweise unterschiedliche Frameworks untersucht, sodass nicht für alle Frameworks alle relevanten Informationen vorliegen. Einen Überblick über die Frameworks und ihre Sicherheit erhält man aber allemal:

  • Adobe AIR wird sowohl auf Mobilgeräten als auch auf dem Desktop eingesetzt, die Apps dafür in Flash oder ActionScript entwickelt. In Adobe AIR wurden bereits sehr viele Schwachstellen behoben, die aber zum größten Teil auf dem verwendeten Adobe Flash Player zurückzuführen sind. Daher sind sie hier weniger relevant, da es nur um die Ausführung des Anwendungscodes geht und im Allgemeinen kein nicht vertrauenswürdiger Code aus dem Internet ausgeführt wird.
  • Basic4android dient der Entwicklung von Android- und Desktop-Apps in BASIC, der Code wird in Java-Code übersetzt. Enthalten sind 33 Java-Libraries. Defaultmäßig erhalten die Apps die folgenden vier Berechtigungen (Permissions):
    android.permission.INTERNET, android.permission.BLUETOOTH,android.permission.WRITE_EXTERNAL_STORAGE, android.permission.BLUETOOTH_ADMIN
    Als Schutzmaßnahme werden Strings obfuskiert und Variablen umbenannt.
  • Cordova und das darauf aufbauende PhoneGap verwenden Webtechniken wie HTML5, JavaScript und CSS3. Cordova implementiert eine Brücke zwischen JavaScript und nativem Code, über die mit JavaScript native Methoden aufgerufen werden können. In Cordova/PhoneGap wurden in der Vergangenheit bereits einige Schwachstellen gefunden. PhoneGap vergibt die Berechtigungen, die der Entwickler konfiguriert, wie zum Beispiel die in Listing 1 aufgeführten.
  • Corona SDK dient zur Entwicklung von 2-D-Spielen und Apps. Die Entwicklung erfolgt in Lua mit Bindings zu C++ und OpenGL. Corona SDK ist mit den Berechtigungen sehr sparsam: Es gibt nur android.permission.INTERNET.
  • Kony-Framework dient zur Entwicklung von Apps in Lua oder JavaScript.
  • RhoMobile dient der Entwicklung von Apps für iOS, Android, Windows Phone und Windows in Ruby sowie HTML/JavaScript/CSS. Die gewünschten Berechtigungen muss der Entwickler deklarieren, dafür stehen elf Werte zur Verfügung. Ein Security-Token beschränkt den Zugriff auf die App, und JavaScript- sowie CSS-Code wird obfuskiert.
  • Titanium Appcelerator dient zur Entwicklung von Mobile-Apps in JavaScript. Der JavaScript-Code läuft in einem Interpreter und nutzt das native UI sowie native Funktionalitäten.
  • Unity dient zur Entwicklung von Spielen in Mono/.NET.
  • Xamarin (früher MonoDroid/MonoTouch) dient der Entwicklung von Apps für iOS, Android, Windows und Mac OSX in C# und .NET.

Generell gelten für alle Lösungen die gleichen Bedenken: Da alle Apps, die das gleiche Framework verwenden, dadurch auch den gleichen Code verwenden, gibt es eine einheitliche Angriffsfläche. Schwachstellen und Angriffe können für verschiedene Apps genutzt werden. Da der Code in einer Hochsprache oder als Bytecode vorliegt, wird Reverse Engineering einfacher oder ist gar nicht nötig.

Listing 1: Auswahl der für Apps verfügbaren Berechtigungen in PhoneGap

android.permission.VIBRATE
android.permission.ACCESS_COARSE_LOCATION
android.permission.ACCESS_FINE_LOCATION
android.permission.ACCESS_LOCATION_EXTRA_COMMANDS
android.permission.READ_PHONE_STATE
android.permission.INTERNET
android.permission.RECEIVE_SMS
android.permission.RECORD_AUDIO
android.permission.MODIFY_AUDIO_SETTINGS
android.permission.READ_CONTACTS
android.permission.WRITE_CONTACTS
android.permission.WRITE_EXTERNAL_STORAGE
android.permission.ACCESS_NETWORK_STATE
android.permission.GET_ACCOUNTS
android.permission.BROADCAST_STICKY

Wie leicht fällt die App-Analyse?

Wie kann ein Angreifer erkennen, mit welchem Framework eine App entwickelt wurde? Und welche Möglichkeiten hat er, um an den Code der App zu gelangen?

  • Adobe-AIR-Apps: Die .swf-Datei mit dem Code befindet sich in Android-Apps unter assets/ und lässt sich leicht dekompilieren (es gibt mehrere Decompiler), sofern sie nicht obfuskiert ist.
  • Basic4android-Apps: Basic4android-Apps lassen sich mit Apktool oder Unzip entpacken, zu erkennen sind sie am Ordner anywheresoftware. Wurde die App im Debug-Modus veröffentlicht, lässt sich der Basic-Code ermitteln. UI-Elemente sind in BAL-Dateien gespeichert, die sich mit dem B4A Designer öffnen lassen.
  • Cordova-/PhoneGap-Apps: Die Apps lassen sich am www/-Unterordner in der App erkennen. Der JavaScript-Sourcecode ist als Klartext in der App enthalten und damit leicht zugänglich. Unter iOS ist er als Ressource mit der App „gebundled“ oder befindet sich im www/-Unterordner im App-Bundle. Unter Android befindet er sich im Ordner assets/ des APK.
  • Corona-Apps: Corona-Apps enthalten die Datei resource.car sowie einen Lib/-Ordner mit den Dateien liblua.so und Libcorona.so.
  • Kony-Framework-Apps: Wurde für die Entwicklung der App Lua verwendet, befindet sich der Code in der Datei konyappluabytecode.o.mp3 innerhalb der App (die Kony-Entwickler scheinen der Meinung zu sein, „Security by Obscurity“ sei eine gute Taktik, oder sie haben einen merkwürdigen Sinn für Humor). Diese Datei kann mit OSS-Decompilern dekompiliert werden.
  • RhoMobile-Apps: RhoMobile-Apps enthalten unter iOS die Datei rhorunner sowie den Ordner Apps/ mit der Datei rhoconfig.txt und den Unterordnern app, lib und public. Unter Android enthalten sie den Ordner Lib/ mit der Datei Librhodes.so sowie den Ordner Apps/ mit der Datei rhoconfig.txt und den Unterordnern app und public. Die Datei rhoconfig.txt enthält einige für den Angreifer interessante Informationen wie die Startseite der App, Informationen über Passwörter, darüber ob der HTTP-Server für das Debugging aktiviert ist oder wo Logs gespeichert werden.
  • Titanium-Appcelerator-Apps: Der eigentliche Code ist in JavaScript geschrieben, Asset-Daten werden zur Laufzeit durch die AssetCryptImpl-Klasse geladen. Sie können mit minimalem Aufwand gelesen und entschlüsselt werden.
  • Unity-Apps: Der .NET-Code lässt sich mit den üblichen Tools dekompilieren, sofern er nicht obfuskiert ist. Zu finden ist er zum Beispiel im assets/-Ordner von Android-Apps.
  • Xamarin-Apps: Xamarin-Apps erkennt man unter iOS an der Datei [App-Name].exe und dem Vorhandensein von Mono-/Xamarin-/App-DLLs, unter Android am Ordner lib/, der in einem Unterordner die Datei libmonodroid.so und Assemblies-Order mit Mono-/Xamarin-/App-DLLs enthält. Die Apps enthalten eine Logfunktion, die interessante Informationen preisgibt. Fehlermeldungen werden entweder im JSON-Format lokal gespeichert oder über HTTP an einen Server gesendet. Es gibt keine Obfuskierung.

Die statische Analyse ist also kein großes Problem für einen Angreifer. Auch eine Obfuskierung schützt nicht zwingend vor einem Angriff, diese lässt sich in den meisten Fällen mit mehr oder weniger viel Aufwand zumindest soweit aufheben, dass eine Analyse des Codes möglich ist.

Während bei nativen Apps nur in App und Libraries nach Schwachstellen gesucht werden kann, kommen bei Cross-Plattform-Apps laut Simon Roses Femerling noch die Konfigurationsdateien hinzu. Wieso diese bei nativen Apps harmlos sein sollten, erschließt sich mir allerdings nicht. Auch native Apps speichern darin mitunter sensible Informationen oder lassen sich darüber manipulieren.

Wie leicht kann ein Angreifer die App manipulieren?

Ist die statische Analyse kein Problem, dann aber doch vielleicht zumindest die Manipulation der Apps, also Angriffe darauf? Wie sieht es also mit dynamischen Manipulationen zur Laufzeit aus? Wenn die möglich sind, sind sie mit wenig oder gar keinen Anpassungen auf alle den angegriffenen Code nutzenden Apps anwendbar.

Als Beispiel für einen Angriff haben Marco Grassi und Sebastián Guerrero Adobe-AIR-Apps ausgewählt, deren In-App-Käufe unter Android sie so manipulieren wollten, dass Käufe als legitim angesehen werden, obwohl sie es nicht sind.

Der für die In-App-Käufe verwendete Code stammt in den meisten Apps in Google Play aus Googles Beispielen. Die für den Angreifer interessante Funktion verifyPurchase lässt sich zum Beispiel mit dem Xposed-Framework so manipulieren, dass sie immer TRUE zurück liefert (außerdem sind einige weitere kleine Änderungen nötig). Prüft die App keine Signaturen auf dem Server, ist der Angreifer damit schon am Ziel: Er kann kostenlos In-App-Käufe tätigen. Und die meisten Apps verzichten in der Tat auf die serverseitige Prüfung.

Laufzeitangriffe auf iOS- und Android-Apps hat Marco Grassi auf der ZeroNights 2014 vorgestellt (Paper / Video).

Schwachstellen in Cordova

Die statische Analyse der App ist kein Problem, die dynamische Manipulation zur Laufzeit auch nicht – und wie sieht es mit ausnutzbaren Schwachstellen in den Frameworks aus? Auch davon gibt es, was von Marco Grassi und Sebastián Guerrero anhand einiger Beispiele belegt wurde. In der Android-Version von Cordova wurden zum Beispiel die folgenden Schwachstellen behoben:

  • CVE-2014-3500: Über einen präparierten Intent-URL kann von entfernten Angreifern die Startseite geändert werden.
  • CVE-2014-3501: Apps können die HTTP-Whitelist umgehen und über WebView WebSocket-Verbindungen zu beliebigen Servern aufbauen.
  • CVE-2014-3502: Apps können via URL Loading-Daten an andere Apps senden.

Adobe AIR

Adobe AIR stellt zwar die Klasse EncryptedLocalStore (ELS) zur verschlüsselten Speicherung von Daten zur Verfügung, diese verschlüsselt die damit gespeicherten Daten unter Android allerdings nicht. Stattdessen werden sie Base64-kodiert gespeichert. Der einzige Schutz dieser Daten vor einem unbefugten Zugriff besteht also darin, dass der private App-Ordner für einen Angreifer nicht zugänglich ist oder besser: nicht zugänglich sein sollte. Die mit Android 4.0 eingeführten ADB-Back-ups speichern den Inhalt privater Apps-Ordner, deren allowBackup-Flag im AndroidManifest.xml auf TRUE gesetzt ist, im Back-up. Ist das Flag nicht vorhanden, wird als Default-Wert TRUE angenommen. Bei Adobe-AIR-Apps ist das Flag in der Default-Einstellung nicht gesetzt. Ein Angreifer mit Zugriff auf das Gerät, der USB-Debugging einschalten kann, kann also die privaten Ordner als Back-up auf dem Rechner sichern und danach die unverschlüsselten Daten lesen.

Titanium Appcelerator

Zu guter Letzt haben sich Marco Grassi und Sebastián Guerrero die Development Tools angesehen. Im Titanium Appcelerator ist die HTTPS-Verschlüsselung unter Android wirkungslos, da das Zertifikat des Servers nicht geprüft wird. Alle damit entwickelten Apps, die die Default-Konfiguration verwenden, sind also für MitM-Angriffe anfällig, auch wenn sie anscheinend HTTPS verwenden. Nur wenn der Entwickler für das Zertifikat ein Pinning spezifiziert hat, wird es geprüft.

Die üblichen Verdächtigen …

Das war nur eine Auswahl von Schwachstellen. Bei der Suche nach Schwachstellen ist Simon Roses Femerling auf die üblichen Verdächtigen gestoßen:

  • Kommunikation in Klartext (Platz 3 der OWASP Top Ten Mobile Risks)
  • Schwache Kryptografie (Platz 6),
  • Nutzung unsicherer Drittherstellerbibliotheken
  • Unsichere Speicherung sensibler Informationen (Platz 2)
  • Preisgabe der App-Logik
  • Unsichere Passwörter (Platz 2)
  • JavaScript-Injection (Platz 7)
  • Sensible Informationen in Konfigurationsdateien (Platz 2)

Er hat darauf verzichtet, konkrete Beispiele zu nennen.

Was haben wir daraus gelernt?

Sicherheit scheint bei Frameworkentwicklern keine besondere Priorität zu genießen. Die Mechanismen, mit denen die Daten der Apps geschützt werden, sind nicht sicher genug. Und dabei haben Marco Grassi und Sebastián Guerrero nicht einmal besonders viel Zeit aufgewendet, um Schwachstellen und Angriffspunkte zu finden. Wie viel mehr Schaden kann dann ein Cyberkrimineller anrichten, der etwas mehr Zeit aufwendet? Simon Roses Femerling hat seine Erfahrungen folgendermaßen zusammengefasst: „Depending on the tech a bit more hard to reverse“, „Suffers the same bugs as native apps“, „Not offering much additional security“.

Den ersten Punkt sehe ich etwas anders. Ich stimme Marco Grassi und Sebastián Guerreros Einschätzung zu, dass das Reverse Engineering bei Cross-Plattform-Apps sehr viel leichter ist als bei nativen Apps. Die liegen selten als Sourcecode vor, Cross-Plattform-Entwicklungen dagegen schon. Und auch wenn der Code als Bytecode vorliegt, lässt dieser sich leichter analysieren als nativer Code.

Die binäre Analyse …

… ist ebenso kein Hexenwerk, auch nicht für Cross-Plattform-Anwendungen. Nathan Li, Loc Nguyen, Xing Li und James Just haben auf der Black Hat USA 2013 das „Taint-enabled Reverse Engineering Environment (TREE) on top of a Cross-platform Binary Automated Symbolic-execution System (CBAS)“ vorgestellt.

Ein Framework, eine Schwachstelle, viele potenzielle Opfer

Kymberlee Price und Jake Kouns (CEO der Open Security Foundation, die die Open Sourced Vulnerability Database OSVDB.org betreibt) haben auf der Black Hat USA 2014 einen Vortrag mit dem Titel „Epidemiology of Software Vulnerabilities: A Study of Attack Surface Spread“ gehalten. Im Vortrag ging es zwar nicht um Cross-Plattform-Frameworks, aber um OpenSSL (nicht erst seit dem Heartbleed Bug berühmt-berüchtigt), FreeType, libpng und FFmpeg. Allerdings betreffen auch diese Bibliotheken mehr als eine Plattform; und die Schwachstellen darin mehr als ein System, ein Programm oder eine App. Außerdem sind die Grundprobleme allgemeingültig, ganz egal, ob eine App nun eine Drittherstellersoftware zur Lösung einer bestimmten Aufgabe nutzt oder um auf mehr als einer Plattform laufen zu können.

Die Ursachen der Schwachstellen

Die Codequalität mancher Open-Source-Projekte lässt stark zu wünschen übrig. Die von Closed-Source-Software ist allerdings auch nicht immer besser, zumindest gibt es auch darin zahlreiche Schwachstellen. Eine Verbesserung dieser Situation ist im Grunde eine Frage des Geldes. Die Projekte haben meist nicht genug Geld, um Code-Audits durchzuführen oder Bug-Bounty-Programme ins Leben zu rufen, was sich seit dem letzten Jahr teilweise zum Besseren gewendet hat, wie beispielsweise Initiativen für Code-Audits für OpenSSL und TrueCrypt zeigen.

Ob Forks von Bibliotheken wie zum Beispiel Google Blink von WebKit oder OpenBSDs LibreSSL von OpenSSL wirklich zielführend sind, um sichereren Code zu erhalten, bleibt abzuwarten. Zumindest ist die Idee, dass man die Sicherheit des Codes nur dann wirklich sicherstellen kann, wenn man die Kontrolle darüber hat, nicht von der Hand zu weisen.

Schwachstellen-History berücksichtigen

Kymberlee Price und Jake Kouns weisen zu Recht darauf hin, dass bei der Auswahl einer Bibliothek etc. auch deren bisherige Schwachstellen-History berücksichtigt werden sollte. Das gilt natürlich auch für die Auswahl einer Cross-Plattform-Technologie. Im Grunde läuft es auf eine einfache Frage hinaus: Gibt es genug Entwickler, um die zu erwartenden Schwachstellen in und Patches bzw. Updates für die Drittherstellerkomponenten zu beherrschen?

Immerhin muss die eigene App zumindest regelmäßig mit der aktuellen Version der Bibliothek getestet und ggf. ausgeliefert werden. Unter Umständen sind auch Anpassungen an neue Versionen oder die Entwicklung von Workarounds für nicht behobene Schwachstellen nötig.

Das sind alles Punkte, die in den Incident-Response-Plan aufgenommen werden müssen. Ist der nur darauf ausgelegt, mit Schwachstellen im eigenen Code umzugehen, bekommen Sie ein Problem, wenn eine kritische Schwachstelle in einer Drittherstellerkomponente entdeckt und womöglich für Angriffe auf Ihre App ausgenutzt wird.

Selbst aktiv werden!

Es kann nicht schaden, selbst aktiv nach Schwachstellen in den verwendeten Frameworks etc. zu suchen. Immerhin müssen Sie Ihre Software ohnehin testen. Wenn Sie dabei auch auf mögliche Schwachstellen in den verwendeten Drittherstellerkomponenten achten, ist das auch in Ihrem eigenen Interesse. Jede Schwachstelle, die Sie selbst entdecken und an die betreffenden Entwickler melden, ist (hoffentlich bald) eine Schwachstelle weniger, die ein Angreifer ausnutzen kann, um Ihrer Software zu schaden.

Ist Cross-Plattform-Entwicklung nun sicher oder unsicher?

Gegen eine Cross-Plattform-Entwicklung sprechen aus Sicherheitssicht einige wenige Punkte:

  1. Eine Schwachstelle im Cross-Plattform-Framework etc. macht alle dieses Framework nutzenden Apps angreifbar.
  2. Die Cross-Plattform-Technologien führen zusätzliche Angriffsflächen ein und enthalten zusätzliche Schwachstellen.
  3. Reverse Engineering gelingt leichter mit Cross-Plattform-Apps.

Gehen wir diese Punkte einmal der Reihe nach durch. Was macht man eigentlich bei der Cross-Plattform-Entwicklung? Man schreibt ein Programm in einer Programmiersprache und verwendet dabei eine Entwicklungsumgebung, ein Framework und/oder Bibliotheken von Drittherstellern, mit deren Hilfe das Programm auf mehreren Plattformen läuft.

Und wie sieht es bei der Entwicklung einer nativen App aus? Da schreibt man ein Programm in einer Programmiersprache und verwendet dabei Bibliotheken etc., um immer wiederkehrende Aufgaben zu lösen.

Ich erkenne da nur einen relevanten Unterschied: Bei der Cross-Plattform-Entwicklung befindet sich zwischen Programm und System eine Vermittlungsschicht, über die das Programm auf die Systemfunktionen zugreift, während ein natives Programm das teilweise direkt macht und teilweise Bibliotheken von Drittherstellern zur Hilfe nimmt.

Wenn es in diesen Drittherstellerkomponenten, egal ob Cross-Plattform-Technik oder native Bibliothek etc., eine Schwachstelle gibt, sind im Allgemeinen alle diese Komponente nutzenden Programme davon betroffen. Daran kann man als Entwickler wenig ändern, wie auch Kymberlee Price und Jake Kouns festgestellt haben. Das ist Aufgabe der Entwickler dieser Komponenten. Als Entwickler einer Anwendung kann man lediglich darauf achten, möglichst schwachstellenarme Komponenten zu verwenden. Unabhängig davon, ob das nun Cross-Plattform-Frameworks oder normale Bibliotheken sind.

Punkt 1 hat sich damit als Argument eigentlich erledigt. Das Gleiche gilt analog für Punkt 2: Ob sich die Schwachstellen nun in einem Cross-Plattform-Framework oder einer Bibliothek für die direkte Nutzung nativer Funktionen befinden, macht keinen Unterschied. Im Vorteil sind nur Apps, die ganz ohne Drittherstellercode auskommen – was die wenigsten tun dürften.

Es gibt nur einen wirklichen Unterschied zwischen Cross-Plattform-Apps und nativen Apps: Der Sourcecode der Cross-Plattform-Apps liegt oft als Klartext vor oder lässt sich relativ leicht aus dem Bytecode ermitteln. Allerdings ist das Reverse Engineering einer nativen App nicht gerade eine der schwersten Übungen, von daher sollte man diesen Nachteil zwar zur Kenntnis nehmen, aber nicht überbewerten. Und bei Bedarf kann den Angreifern eine Obfuskierung die Arbeit erschweren. Auch Punkt drei ist also nicht wirklich stichhaltig, vor allem dann nicht, wenn man bedenkt, wie viele Schwachstellen es in Closed-Source-Software gibt. Zum Beispiel Adobe Reader, Flash Player, Java und IE, die immer wieder erfolgreich angegriffen werden, obwohl Cyberkriminelle keinen Zugriff auf deren Sourcecode haben.

Wie sieht es mit den Sicherheitsfunktionen aus?

Damit bleibt nur noch eine Frage zu klären: Wie sicher sind Cross-Plattform-Techniken? Im PhoneGap-Wiki steht dazu unter „Platform Security“: „PhoneGap is generally limited to the security features of the platform on which it is running“. Das stimmt nicht ganz – nichts und niemand hindert die Entwickler daran, ihre Cross-Plattform-Frameworks mit zusätzlichen Schutzmaßnahmen zu versehen. Funktionieren diese wie im Fall der Klasse EncryptedLocalStore in Adobe AIR nicht, ist das ein anderes Problem. Aber auch Adobe-AIR-Apps sind immer noch so sicher, wie die zugrunde liegende Plattform. Dass sich ein Angreifer unter Android Zugriff auf den privaten Ordner der App verschaffen kann, kann man Adobe AIR nicht anlasten. Natürlich ist es fatal, wenn der App-Entwickler meint, er hätte die Daten verschlüsselt gespeichert, und sich dann herausstellt, dass sie nur umkodiert wurden.

Aber das ist eine Schwachstelle, die behoben werden muss. Dass sie sich in einer Cross-Plattform-Lösung befindet, ist dabei irrelevant. Sie hätte sich ja genauso gut auch in einer nativen Kryptobibliothek befinden können, mit der der App-Entwickler seine Daten verschlüsseln will.

Fazit

Cross-Plattform-Technologien erhöhen die Angriffsfläche der Apps, und eine Schwachstelle in einer solchen Technologie betrifft alle diese nutzenden Apps. Das gilt gleichermaßen für alle Bibliotheken, die native Apps nutzen.

Hat schon einmal irgendjemand gefordert, aus Sicherheitsgründen auf Drittherstellerkomponenten zu verzichten und alles selbst zu implementieren? Ich glaube nicht. Das wäre auch nicht besonders sicher, denn in vielen Fällen ist es besser, die Implementierung Spezialisten zu überlassen, da man selbst noch viel mehr Fehler und Schwachstellen machen würde.

Also: Nutzen Sie ruhig Cross-Plattform-Techniken. Ihre Programme werden dadurch auch nicht viel unsicherer, als sie es bei der Nutzung nativer Bibliotheken würden. Achten Sie bei der Prüfung der fertigen App sicherheitshalber darauf, dass alle auf der jeweiligen Zielplattform verfügbaren Schutzmaßnahmen auch genutzt werden und dass die App allgemein die Anforderungen an eine sichere App erfüllt, also zum Beispiel nur die wirklich benötigten Rechte für sich reklamiert. Manche Cross-Plattform-Frameworks sind in dieser Hinsicht recht freigiebig.

Aufmacherbild: businessman hand showing 3d padlock via Shutterstock / Urheberrecht: everything possible

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -