Safety first – Mobile Security
November 18, 2015
Aus dem Unterricht des CAS Mobile Business mit Jan Alsenz berichtet Andreas Kemp:
Am heutigen Vormittag erhalten wir von Jan Alsenz eine ordentliche Dosis Informationen über die Grundlagen der digitalen Sicherheit. Schnell stellt sich die Frage: Was bedeutet Sicherheit überhaupt? Um sich ein Gesamtbild machen zu können, wird sie in folgende Gruppen unterteilt.
Zentrale Definition von Sicherheitsmechanismen:
- Vertraulichkeit (z.B. Verschlüsselung)
- Integrität (z.B. kryptografische Message-Authentication-Codes)
- Verfügbarkeit (z.B. Redundanz)
Zusätzliche Sicherheitsmechanismen:
- Nichtabstreitbarkeit (z.B. Signaturen)
- Authentizität (z.B. Passwörter, Zertifikate)
- Anonymität (z.B. Onion-Router)
Anhand der OWASP Top 10 werden die gängigsten Sicherheitslücken aufgezeichnet – ursprünglich nur für Web-, nun auch für Mobile-Applikationen:
M1: Weak Server Side Controls
Die schwachen serverseitigen Schutzmechanismen gehören zu den klassischen Sicherheitslücken im Backend-Bereich. So können Sicherheitsprobleme wie beispielsweise das unbefugte Auslesen von Datenbanken oder Ausführen von Programmcodes auf Servern entstehen. Sichere Programmierung ist die beste Prävention, um das Backend vor Manipulation zu schützen. Beispiele und Szenarien.
M2: Insecure Data Storage
Auf den vorderen Rängen der OWASP-Liste befindet sich die unsichere Datenspeicherung. Ein Beispiel hierfür ist die lokale, unverschlüsselte Speicherung von sensiblen Daten wie Passwörtern im Klartext als auch Cloud-synchronisierte Daten. Für Mailware oder Jailbreak grundsätzlich auslesbar! So sollten sensible Daten grundsätzlich mit Benutzername/Passwort verschlüsselt werden. Details und Best Practices für die Prävention (iOS/Andorid).
M3: Insufficient Transport Layer Protection
Es muss davon ausgegangen werden, dass sämtliche Netzwerke, welche sich nicht unter eigener Kontrolle befinden, eine Gefahr sind. Ungenügender Schutz bei der Datenübertragung passiert oft bei schlechter Server-Authentifizierungs-Prüfung (abgelaufene oder selbstgebastelte Zertifikate; User-Tracking bei Drittplattformen; etc.). Ob die eigenen Schutzmechanismen greifen, zeigt sich bei Tests für alle Verbindungen über fremde Netze oder durch einen Proxy. Informationen über ineffizienten Schutz der Datenübertragung auf OWASP.
M4: Unintended Data Leakage
Mobile Anwendungen mit hoher Integrität sind für Anwenderinnen und Anwender ein Segen. Jedoch kann es sehr schnell passieren, dass sicherheitskritische Daten unbemerkt abfliessen. Aus Developer-Sicht ist es entscheidend, zu wissen, was das OS und die eingesetzten Frameworks und SDKs tun, um einen unbeabsichtigten Datenabfluss zu verhindern. Debug-Funktionen sollten in produktiven Apps vermieden/deaktiviert werden. Weitere Szenarien und Präventionsmassnahmen auf OWASP.org.
M5: Poor Authorization and Authentication
Man kann davon ausgehen, dass lokale Autorisierungs- und Authentifikations-Mechanismen umgangen werden können. Schwache Passwörter und PINs tun ihr übriges. So sollten möglichst starke Passwörter mit mindestens zehn Zeichen und einem Mix aus Zahlen, Buchstaben (Gross- und Kleinschreibweise) und Sonderzeichen verwendet werden.
Developer müssen bei der Entwicklung davon ausgehen, dass Autorisierungs- und Authentifikations-Kontrollen umgangen werden. So müssen beispielsweise Formulareingaben serverseitig erneut geprüft werden. Weiterführende Informationen zu Poor Authorization and Authentication auf OWASP.
M6: Broken Cryptography
Selbstentwickelte Alogrithmen oder Protokolle sind der einfachste Weg, defekte Kryptografie zu produzieren. Kryptografische Funktionen und Protokolle sollten durch Experten implementiert werden und wenn möglich den Standardmethoden wie beispielsweise SSL/TLS, System Keychains etc. entsprechen.
M7: Client Side Injection
Mit der Client-seitigen Injektion wird schlecht oder gar nicht gefilterter Schadcode in das System eingeschleust. So können beispielsweise mit Steuerzeichen Manipulationen vorgenommen werden, wie das Auslesen von Daten und Einstellungen; Code kann ausführbar gemacht werden, etc. Die Angriffspunkte können vermieden werden, wenn Steuerzeichen gefiltert bzw. codiert werden und generell die Bibliotheken der SDKs verwendet werden. Details zu XSS und SQL-Injection auf OWASP.
M8: Security Decisions Via Untrusted Inputs
Ein Angreifer kann die Anrufe (IPC- oder Web-Service-Aufrufe) abfangen und sensible Parameter weiter verwenden. Schwache Sicherheitsentscheide auf nicht vertrauenswürdigen Eingaben führen zu missbräuchlichem Verhalten einer App und können einem Angreifer sogar höhere Berechtigungen erteilen. Sämtliche Eingaben auf allen Kanälen, die nicht standardmässige Authentisierung bieten, müssen als potentiell bösartig beurteilt werden. Details auf OWASP.org.
M9: Improper Session Handling
Beim ungenügenden Session Handling werden Sessions backendseitig nicht korrekt abgewickelt. Unsachgemässer Umgang mit Sessions führt in der Regel zum gleichen Ergebnis wie schlechte Authentifizierung. So ist es wichtig, dass geeignete Timeouts eingerichtet werden und keine selbstgebastelten Mechanismen für die Generierung von Tokens erstellt werden.
M10: Lack of Binary Protections
Mittels Reverse Engineering können fehlende Binär-Schutzmechanismen dazu führen, dass einerseits geistiges Eigentum aus der App extrahiert wird und andererseits Funktionen in der App verändert werden können. Bei fehlenden Binär-Schutzmechanismen können sämtliche Funktionen rekonstruiert werden. Da ein vollständiger Schutz nicht möglich ist, kann eine Verschleierungstaktik die Arbeit der Angreifer erschweren. Auf Mobile Devices ohne Jail-Break sind die Methoden jedoch ausreichend.
Auf unseren mobilen Geräten laufen Datenströme von unterschiedlichen Quellen zusammen. Das mobile Interface ist unser Cockpit für alle Belange. So häufen sich sensible Daten, zu denen wir selbst Sorge tragen müssen. Dessen sind sich auch die Anbieter von Dienstleistungen und Apps bewusst. Sicherheit heisst Prävention – seitens Development und auch auf Anwenderseite. Für die richtige Anwendung ist Expertenwissen gefragt; eigene Sicherheits-Anwendungen arten oft als gut gemeinte Bastelarbeit aus.