Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 5

[caption id="attachment_2950" align="alignleft" width="224" caption="@elektrojunge on stage"][/caption] 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. 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 Basier 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.