Die 10 wichtigsten Risiken von OWASP Mobile anhand von Fällen aus der Praxis verstehen
Veröffentlicht: 2020-01-28Der Branchenrekord in der Entwicklung von 100 % hacksicheren Anwendungen ist mit einer Verantwortung und einer grundlegenden Garantie verbunden, dass keine der unter unserem Namen entwickelten digitalen Lösungen einer Sicherheitsverletzung ausgesetzt ist.
Um dies zu erreichen, ist das Qualitätssicherungsteam von Appinventiv mit allen möglichen Sicherheitsrisiken vertraut, denen eine App ausgesetzt sein kann. Wenn Sie die Risiken kennen, können Sie Fallstricke leicht ignorieren und sichere Apps schreiben.
Wenn es um die Gewährleistung der Sicherheit geht, helfen Sie uns, an der Spitze des Spiels zu stehen, wenn wir über umfassende Kenntnisse der sicheren Codierungspraktiken von OWASP (Open Web Application Security Project) verfügen. Es handelt sich um eine Online-Community von Sicherheitsspezialisten, die kostenlose Dokumentationen, Lernmaterialien und Tools zum Erstellen sicherer Mobil- und Webanwendungen entwickelt haben.
Neben anderen Dingen haben sie auch eine Liste der OWASP Mobile Top 10 Sicherheitsbedrohungen in mobilen Anwendungen zusammengestellt.
Obwohl das Dokument zu den OWASP-Sicherheitspraktiken ziemlich klar ist, kann es für Unternehmen manchmal schwierig sein, es mit realen Fällen zu verbinden.
In diesem Artikel geben wir Ihnen einen grundlegenden Überblick über die Top 10 der Sicherheitsrisiken für Mobilgeräte und geben Beispiele für die in der Praxis offengelegten Schwachstellen für jedes dieser Risiken. Es gibt Ihnen einen Einblick, worauf wir uns bei Appinventiv vorbereiten, wenn wir an Ihrer Bewerbung arbeiten.
Bevor wir uns mit den Risiken befassen, werfen wir einen Blick auf die Statistiken.
NowSecure untersuchte die Apps im Google Play Store und im App Store und stellte fest, dass über 85 % der Apps gegen eines der Risiken verstoßen.
Von diesen Anwendungen hatten 50 % eine unsichere Datenspeicherung und irgendwo die gleiche Anzahl von Apps arbeiteten mit einem unsicheren Kommunikationsrisiko . Hier ist ein Diagramm, das den Prozentsatz des Auftretens der Top-10 - Risiken von OWASP Mobile zeigt
Liste der 10 häufigsten Bedrohungen für mobile Anwendungen und die Best Practices zu ihrer Vermeidung
M1: Unsachgemäße Plattformnutzung
Die Kategorie der OWASP-Sicherheitstests besteht aus dem Missbrauch einer Gerätefunktion oder dem Ausfall bei der Verwendung der Sicherheitskontrollen der Plattform. Dies kann Plattformberechtigungen, Android-Absichten, Missbrauch der TouchID, des Schlüsselbunds usw. umfassen.
Fall aus der realen Welt:
Drei iOS-Apps : „Fitness Balance App“, „Heart Rate Monitor“ und „Calories Tracker App“ kamen ans Licht, weil sie Apples Touch ID umgingen. Sie baten die Benutzer, ihren Fingerabdruck zu verwenden, um Fitnessinformationen zu erhalten, während sie damit Geld aus dem App Store abbuchten.
Best Practice zu vermeiden:
- Der Entwickler darf Schlüsselbundverschlüsselungen über die Serverroute nicht zulassen und die Schlüssel nur auf einem Gerät aufbewahren, damit sie nicht auf anderen Servern oder Geräten ausgenutzt werden können.
- Der Entwickler muss die App über den Schlüsselbund sichern, um das Geheimnis der App zu speichern, das über eine dedizierte Zugriffssteuerungsliste verfügt.
- Der Entwickler muss die Erlaubnis einholen, um einzuschränken, welche Apps mit ihrer Anwendung kommunizieren dürfen.
- Der Entwickler muss die erste der OWASP Mobile Top 10-Liste kontrollieren, indem er die expliziten Absichten definiert und somit alle anderen Komponenten blockiert, um auf Informationen zuzugreifen, die in der Absicht enthalten sind.
M2: Unsichere Datenspeicherung
OWASP betrachtet es als Bedrohung, wenn jemand Zugriff auf ein verlorenes/gestohlenes mobiles Gerät erhält oder wenn Malware oder eine andere neu verpackte App beginnt, im Namen des Angreifers zu handeln und Aktionen auf dem mobilen Gerät ausführt.
Eine Schwachstelle in der unsicheren Datenspeicherung führt normalerweise zu diesen Risiken:
- Betrug
- Identitätsdiebstahl
- Materieller Verlust.
- Reputationsschaden
- Verstoß gegen externe Richtlinien (PCI)
Fall aus der realen Welt :
Dating-Apps wie Tinder, OKCupid und Bumble wurden immer wieder auf ihre unsicheren Datenspeicherpraktiken hin untersucht. Die in diesen Apps vorhandenen Sicherheitslücken variieren je nach Machbarkeit und Schweregrad und Machbarkeit, können den Namen, die Anmeldedaten, den Nachrichtenverlauf und sogar den Standort der Benutzer zusätzlich zu anderen persönlichen Kontoaktivitäten offenlegen.
Zu vermeidende Best Practices:
- Für iOS empfehlen die OWASP-Sicherheitspraktiken die Verwendung von absichtlich erstellten anfälligen Apps wie iGoat, um ihr Entwicklungsframework und ihre Apps auf Bedrohungen zu modellieren. Dies hilft den Entwicklern von iOS-Apps zu verstehen, wie APIs mit den App-Prozessen und Informationsressourcen umgehen.
- Die Android-App-Entwickler können die Android Debug Bridge-Shell verwenden, um die Dateiberechtigungen der Ziel-App und DBMS zu überprüfen, um die Datenbankverschlüsselung zu überprüfen. Sie sollten auch das Memory Analysis Tool und den Android Device Monitor verwenden, um sicherzustellen, dass der Gerätespeicher keine unbeabsichtigten Daten enthält.
M3: Unsichere Kommunikation
Bei der Entwicklung einer mobilen App werden Daten im Client-Server-Modell ausgetauscht. Wenn die Daten übertragen werden, sollten sie also zuerst das Trägernetzwerk des Geräts und das Internet durchlaufen. Die Bedrohungsagenten könnten Schwachstellen ausnutzen und vertrauliche Daten abfangen, während sie über Kabel übertragen werden. Hier sind die verschiedenen Bedrohungsagenten, die es gibt:
- Gegner, der Ihr lokales Netzwerk teilt – ein kompromittiertes Wi-Fi
- Netzwerk- oder Trägergeräte – Mobilfunkmasten, Proxy, Router usw.
- Malware auf dem Mobilgerät.
Das Abfangen sensibler Daten über einen Kommunikationskanal würde zu einer Verletzung der Privatsphäre führen, was zu Folgendem führen kann:
- Identitätsdiebstahl
- Betrug
- Reputationsschaden.
Fall aus der realen Welt:
Das Sicherheitsunternehmen Rapid7 hat mehrere Sicherheitslücken in Kinder-Smartwatches offengelegt. Diese Uhren wurden als solche vermarktet, die von Eltern verwendet wurden, um ihre Kinder zu verfolgen und ihnen Nachrichten zu senden oder Anrufe auf ihrer Smartwatch zu tätigen.
Die Uhren sollten von zugelassenen Kontaktnummern über den Modus einer Whitelist kontaktiert werden, aber das Unternehmen stellte fest, dass die Filter nicht einmal funktionierten. Die Uhren akzeptierten sogar Konfigurationsbefehle per SMS. Dies bedeutete, dass ein Hacker die Einstellungen der Uhr ändern und Kinder gefährden könnte.
„Sie können feststellen, wo sich das Telefon oder das Kind befindet, Sie können auf Audio zugreifen oder Kinder anrufen“, sagte Deral Heiland, IoT-Forschungsleiter bei Rapid7.
Zu vermeidende Best Practices:
- Entwickler sollten nicht nur nach Datenlecks suchen, die zwischen App und Server kommuniziert werden, sondern auch nach Geräten, auf denen sich die App befindet, und anderen Geräten oder lokalen Netzwerken.
Die Anwendung von TLS/SSL für den Transport von Kanälen ist auch eine der Best Practices für die Sicherheit mobiler Apps , die bei der Übertragung sensibler Informationen und anderer sensibler Daten zu berücksichtigen sind.
- Verwenden Sie Zertifikate, die von vertrauenswürdigen SSL-Kettenüberprüfungen stammen.
- Senden Sie sensible Daten nicht über alternative Kanäle wie MMS, SMS oder Push-Benachrichtigungen.
- Wenden Sie eine separate Verschlüsselungsebene auf vertrauliche Daten an, bevor Sie sie an den SSL-Kanal weitergeben.
M4: Unsichere Authentifizierung
Die Bedrohungsagenten, die Authentifizierungsschwachstellen ausnutzen, tun dies über automatisierte Angriffe, bei denen speziell entwickelte oder verfügbare Tools verwendet werden.
Die geschäftlichen Auswirkungen von M4 können sein:
- Informationsdiebstahl
- Reputationsschaden
- Unbefugter Zugriff auf Daten.
Fall aus der realen Welt :
Im Jahr 2019 wurde eine US-Bank von einem Cyber-Angreifer gehackt, der den Website-Fehler der Bank ausnutzte und die Zwei-Faktor-Authentifizierung umging, die zum Schutz von Konten implementiert wurde.
Der Angreifer loggte sich mit gestohlenen Zugangsdaten des Opfers in das System ein und verwendete beim Erreichen der Seite, auf der PIN oder Sicherheitsantwort eingegeben werden musste, eine manipulierte Zeichenfolge in der Web-URL, die den Computer als erkannt eingestellt hatte. Dies ermöglichte es ihm, die Bühne zu überqueren und die Überweisungen einzuleiten.

Zu vermeidende Best Practices:
- Das App-Sicherheitsteam muss die App-Authentifizierung untersuchen und sie durch binäre Angriffe im Offlinemodus testen, um festzustellen, ob sie ausgenutzt werden kann.
- Die Sicherheitsprotokolle zum Testen von OWASP-Webanwendungen müssen mit denen von mobilen Apps übereinstimmen.
- Verwenden Sie so viel wie möglich Online-Authentifizierungsmethoden, genau wie im Falle eines Webbrowsers.
- Aktivieren Sie das Laden von App-Daten erst, wenn der Server die Benutzersitzungen authentifiziert hat.
- Stellen Sie sicher, dass die Orte, an denen lokale Daten verwendet werden, durch einen verschlüsselten Schlüssel verschlüsselt sind, der von den Anmeldeinformationen der Benutzer abgeleitet wird.
- Die persistente Authentifizierungsanforderung muss auch auf dem Server gespeichert werden.
- Das Sicherheitsteam sollte mit gerätezentrierten Autorisierungstoken in der App vorsichtig sein, da die App angreifbar werden kann, wenn das Gerät gestohlen wird.
- Da der unbefugte physische Zugriff auf Geräte üblich ist, muss das Sicherheitsteam eine regelmäßige Authentifizierung der Benutzeranmeldeinformationen vom Server aus erzwingen.
M5: Unzureichende Kryptografierisiken
Die Angreifer sind in diesem Fall diejenigen, die den physischen Zugriff auf falsch verschlüsselte Daten haben. Oder wenn eine Malware im Namen eines Gegners handelt.
Gebrochene Kryptografie führt im Allgemeinen in diesen Fällen zu:
- Informationsdiebstahl
- Diebstahl von geistigem Eigentum
- Code-Diebstahl
- Datenschutzverletzungen
- Reputationsschaden.
Fall aus der realen Welt :
Vor einiger Zeit warnte eine Warnung des Cyber Emergency Response Teams von DHS Industrial Control Systems und des Philips Advisory die Benutzer vor einer möglichen Schwachstelle in der Android-App Philips HealthSuite Health .
Das Problem, das auf eine unzureichende Verschlüsselungsstärke zurückgeführt wurde, öffnete die App für Hacker, die Zugriff auf die Herzfrequenzaktivität, den Blutdruck, den Schlafzustand, die Gewichts- und Körperzusammensetzungsanalyse der Benutzer usw. erhalten konnten.
Zu vermeidende Best Practices:
- Um dieses eines der am häufigsten auftretenden OWASP Top 10 Mobile-Risiken zu lösen , müssen Entwickler moderne Verschlüsselungsalgorithmen für die Verschlüsselung ihrer Apps wählen. Die Wahl des Algorithmus kümmert sich weitgehend um die Schwachstelle.
- Wenn der Entwickler kein Sicherheitsexperte ist, muss er davon absehen, eigene Verschlüsselungscodes zu erstellen.
M6: Unsichere Autorisierungsrisiken
In diesem Fall sind die Bedrohungsagenten in der Lage, auf die Anwendung einer anderen Person zuzugreifen, typischerweise über automatisierte Angriffe, die speziell entwickelte oder verfügbare Tools verwenden.
Es kann zu folgenden Problemen führen:
- Informationsdiebstahl
- Reputationsschaden
- Betrug
Fall aus der realen Welt :
Die Informationssicherheitsspezialisten von Pen Test Partners haben Pandora , ein intelligentes Autoalarmsystem, gehackt. Theoretisch wird die Anwendung verwendet, um ein Auto zu verfolgen, den Motor abzustellen, wenn es gestohlen wird, und es zu sperren, bis die Polizei eintrifft.
Auf der anderen Seite der Medaille kann ein Hacker das Konto kapern und Zugriff auf alle Daten und die intelligenten Alarmfunktionen erhalten. Außerdem könnten sie:
- Fahrzeugbewegungen verfolgen
- Alarmsystem aktivieren und deaktivieren
- Autotüren verriegeln und entriegeln
- Den Motor abstellen
- Im Fall von Pandora erhielten Hacker über das Mikrofon der Diebstahlsicherung Zugriff auf alles, worüber im Auto gesprochen wurde.
Zu vermeidende Best Practices:
- Das QA-Team muss die Benutzerrechte regelmäßig testen, indem es Sitzungstoken mit niedrigen Rechten für die sensiblen Befehle ausführt.
- Der Entwickler muss beachten, dass die Benutzerautorisierungsschemata im Offline-Modus schief gehen.
- Die beste Möglichkeit, dieses Risiko zu vermeiden, besteht darin, Autorisierungsprüfungen für Berechtigungen und Rollen eines authentifizierten Benutzers auf dem Server statt auf dem Mobilgerät durchzuführen.
M7: Risiken bei schlechter Codequalität
In diesen Fällen werden nicht vertrauenswürdige Eingaben von Entitäten an Methodenaufrufe weitergegeben, die im mobilen Code durchgeführt werden. Eine Folge davon können technische Probleme sein, die zu einer Verschlechterung der Leistung, einer starken Speichernutzung und einer schlecht funktionierenden Front-End-Architektur führen können.
Fall aus der realen Welt :
WhatsApp hat letztes Jahr eine Schwachstelle gepatcht, die Hacker ausnutzten, um Überwachungs-Malware namens Pegasus Spyware auf Smartphones zu installieren. Alles, was sie tun mussten, war, einen WhatsApp-Audioanruf auf den Zieltelefonnummern zu tätigen.
Innerhalb weniger einfacher Schritte konnten Hacker in die Geräte der Benutzer eindringen und aus der Ferne darauf zugreifen.
Zu vermeidende Best Practices:
- Gemäß den OWASP-Praktiken für sichere Codierung sollte der Code auf dem Mobilgerät neu geschrieben werden, anstatt ihn auf der Serverseite zu reparieren. Die Entwickler müssen beachten, dass sich schlechtes Coding auf Serverseite stark von schlechtem Coding auf Client-Ebene unterscheidet. Das heißt, sowohl schwache serverseitige Kontrollen als auch clientseitige Kontrollen sollten getrennt beachtet werden.
- Der Entwickler muss Tools von Drittanbietern für die statische Analyse verwenden, um Pufferüberläufe und Speicherlecks zu identifizieren.
- Das Team muss eine Bibliotheksliste von Drittanbietern erstellen und diese regelmäßig auf neuere Versionen überprüfen.
- Entwickler sollten alle Client-Eingaben als nicht vertrauenswürdig ansehen und sie validieren, unabhängig davon, ob sie von Benutzern oder der App stammen.
M8: Risiken der Codemanipulation
Normalerweise nutzt ein Angreifer in diesem Fall eine Codeänderung über bösartige Formen der Apps aus, die in den App-Stores von Drittanbietern gehostet werden. Sie können Benutzer auch durch Phishing-Angriffe dazu verleiten, eine Anwendung zu installieren.
Zu vermeidende Best Practices:
- Die Entwickler müssen sicherstellen, dass die App Codeänderungen zur Laufzeit erkennen kann.
- Die build.prop-Datei muss auf das Vorhandensein von inoffiziellem ROM in Android überprüft werden und um herauszufinden, ob das Gerät gerootet ist.
- Der Entwickler muss Prüfsummen verwenden und die digitalen Signaturen auswerten, um festzustellen, ob eine Dateimanipulation stattgefunden hat.
- Der Codierer kann sicherstellen, dass die App-Schlüssel, der Code und die Daten entfernt werden, sobald eine Manipulation festgestellt wird.
M9: Reverse-Engineering-Risiko
Ein Angreifer lädt normalerweise die Ziel-App aus dem App Store herunter und analysiert sie in seiner lokalen Umgebung mit einer Reihe verschiedener Tools. Anschließend können sie den Code ändern und die App anders funktionieren lassen.
Fall aus der realen Welt :
Pokemon Go sah sich kürzlich den Blicken der Sicherheitsverletzung gegenüber, als festgestellt wurde, dass Benutzer die App zurückentwickelt hatten, um die Umgebung der Pokemons zu kennen und sie innerhalb von Minuten zu fangen.
Zu vermeidende Best Practices:
- Der beste Weg, eine App vor dem Risiko zu schützen, besteht laut OWASP Mobile Security darin, dieselben Tools zu verwenden, die die Hacker für das Reverse Engineering verwenden würden.
- Der Entwickler muss auch den Quellcode verschleiern, damit er schwer lesbar wird, und dann zurückentwickeln.
M10: Fremdfunktionsrisiko
Normalerweise untersucht ein Hacker die Fremdfunktionalität innerhalb einer mobilen App, um die versteckten Funktionalitäten in den Backend-Systemen zu entdecken. Der Angreifer würde irrelevante Funktionen von seinen eigenen Systemen ausnutzen, ohne dass Endbenutzer beteiligt sind.
Fall aus der realen Welt :
Die Idee der Wifi File Transfer App war es, den Port auf Android zu öffnen und Verbindungen vom Computer zuzulassen. Das Problem ? Das Fehlen einer Authentifizierung wie Passwörter, was bedeutet, dass sich jeder mit einem Gerät verbinden und vollen Zugriff erhalten kann.
Zu vermeidende Best Practices:
- Stellen Sie sicher, dass der endgültige Build keinen Testcode enthält
- Stellen Sie sicher, dass es keinen versteckten Schalter in den Konfigurationseinstellungen gibt
- Protokolle dürfen keine Prozessbeschreibung des Back-End-Servers enthalten
- Stellen Sie sicher, dass die vollständigen Systemprotokolle von den OEMs nicht für Apps verfügbar gemacht werden
- Die API-Endpunkte müssen gut dokumentiert sein.