Vortrag 5:
Safety First, Android sicher programmieren!
Es gibt Dinge zu beachten, die nur für mobile Endgeräte gelten.
Android ist strukturiert wie ein Orchester mit vielen „Spielern“, verschiedensten Komponenten, die erst zur Laufzeit miteinander verknüpft durch die „Intents“ die Messengerkomponenten. Wie kann ich nun diese Komponenten absichern, wenn Intents schief laufen.
Es gibt das grobgranulare Sicherheitsmodell basierend auf der Sicherheit des Linux Kernels, der die Prozesse isoliert.
Desktop hat Single UID
Android hat UID per Application
Applikationen, die mit dem gleichen Schlüssel signiert sind, können mit der gleichen UID laufen.
Die Kommunikation zwischen Apps läuft über eine Binder IPC
Weiterer Schutz->Sandboxing von Applikationen
Ich kann nur meine eigenen Ressourcen ansprechen.
Jede App läuft in einer eigenen Instanz der Dalvik VM.
Kommunikation über spezielle Interfaces.
Weiterer Sicherheitsmechanismus
Signieren von Applikationen
Verantwortlich für die Signatur ist der Entwickler
Zertifizierung durch Entwickler und in Verantwortung des Entwicklers
Vertrauen in Entwickler durch Erstellung guter Anwendungen
Daneben Feingranulares Sicherheitskonzept
Basiert auf Permissions
Permissions schränken die Möglichkeiten ein, was Prozesse tun können.
Benutzer erkennt das an den angegebenen Rechten, die die App bei der Installation fordert.
Es gibt:
System permissions Erlaubnis auf Systemdienste zuzugreifen (z.B) Kalender oder Adressbuch
Custom permissions
Permission groups
Permission trees
Definiert werden die Permissions im Android Manifest.
Informationen über Apps und laufende Prozesse kann über PackageManager oder ActivityManager
PackageManager -> Installierte Programme
ActivityManager -> Laufende Programme
Wo sind die Verantwortlichkeiten des Entwicklers?
Per Default kann eine App vom „Umfeld“ nichts sehen.
Component wird exportiert durch android:exported im Intentsfilter
Intents sind vergleichbar mit Messengerobjekten
Niemals sensitive Daten in einen Intent
Ebenso von Anfang an angeben, wer den Intent sehen können soll.
Intentfilter filtern keine schädlichen Intents!
Ein Angreifer kann die Priorität seiner Intentfilter erhöhen.
Bei Intentfiltern spezifische Aktionen und Kategorien angeben und Datenfilter
Activities
Benuten von Activity android:permissions = „de.otw.android.HARM_USER_DATA“
Die Permissions werden in startActivity() bzw. startActivityforResult() geprüft.
Services
Client-> Intent.setComponent() um den Service eindeutig zu identifizieren.
Achtung bei der Verwendung von Binder Interface.
Genehmigung für ServiceConnection im Package Manager prüfen, vor dem Austausch sensitiver Daten.
Server: Genehmigung mit erzwingen
Feingranularere Zugriffskontrolle durch Verwendung von Binder und Context Hilfsfunktionen
Broadcast Receiver
Receiver: Wiederum eine Genehmigung erzwingen
Sender: Immer darüber nachdenken, wer den Intent empfangen können soll. Also einfordern einer Permission und Definieren des Empfängers des Intents.
Don’t user sticky broadcasts for sensitive data!
ContentProvider
Achtung, beim Verwenden eines ContentProvider intern, android:exported=“false“ explizit setzen.
Lese und Schreibrechte trennen
android:readPermission
android;writePermission
TAg schränkt zur Compiletime uri Zugriffe ein.
Mitkönne erlaubte Pfade für uri Zugriffe angegeben werden.
Tips:
Jegliche empfangene Daten aus einem Intent prüfen
SQL Statement und Daten die es enthält klar trennen.
Selection fields final machen um Kontaminierung aus Zufall zu vermeiden
Selektionen komplett vermeiden, Content_uris verwenden.
File I/O
Files, DB und geteilte Preferenzen könne mit Berechtigung installiert werden
Bei Zugriffsberechtigungen auf Datenbanken immer an die Konsequenzen denken und immer den User fragen.
Daten auf SD Karte NIE unverschlüsselt ablegen.
IMMER DRAN DENKEN Nutzerdaten SICHER speichern.
So wenig Permissions wie möglich, anstelle einer Permission manchmal besser ein Dialog.