Was Sie beim Entwickeln sicherer Apps beachten müssen

Windows Phone und die Sicherheit (Teil 3)
Kommentare

Windows Developer

Der Artikel „Windows Phone und die Sicherheit“ von Carsten Eilers ist erstmalig erschienen im Windows Developer 9.2012
Secure-Sockets-Layer(SSL-)Zertifikate
Eigentlich sollte man erwarten,

Windows Developer

Der Artikel „Windows Phone und die Sicherheit“ von Carsten Eilers ist erstmalig erschienen im Windows Developer 9.2012

Secure-Sockets-Layer(SSL-)Zertifikate

Eigentlich sollte man erwarten, dass es bei SSL keine Besonderheiten gibt. Leider ist dem nicht so: Die Liste vertrauenswürdiger Zertifizierungsstellen, deren Root-Zertifikate bereits in Windows Phone enthalten sind [13], ist deutlich kürzer als bei Desktopsystemen.

Sind Sie auf eine HTTPS-Verbindung zu einem Server angewiesen, dessen Zertifikat sich nicht zu einem der enthaltenen Root-Zertifikate zurückverfolgen lässt, müssen Sie erst das passende Root-Zertifikat installieren, bevor die Verbindung aufgebaut werden kann. Technisch ist das kein Problem, da weitere Root-Zertifikate hinzugefügt werden können. Organisatorisch sieht es da etwas anders aus: Warum sollte der Benutzer einem neuen Root-Zertifikat vertrauen? Vor allem, wenn er beim Aufruf Ihres Servers gewarnt wird, dass der nicht vertrauenswürdig ist? Im Allgemeinen ist es daher einfacher, wenn Sie sich ein Zertifikat bei einer der von Microsoft für Windows Phone als vertrauenswürdig eingestuften Zertifizierungsstellen besorgen. Die geringe Zahl vertrauenswürdiger Zertifizierungsstellen hat aber auch einen Vorteil: Die vielen ab Werk für vertrauenswürdig erklärten Zertifizierungsstellen haben bei den Desktopsystemen schon mehrmals zu Schwachstellen geführt, weil Zertifizierungsstellen kompromittiert wurden oder absichtlich „gefälschte“ Zertifikate ausgestellt haben [14]. Diese Gefahr ist durch die geringe Zahl vertrauenswürdiger Zertifizierungsstellen deutlich geringer.

Eine weitere Einschränkung betrifft nur die wenigsten Entwickler: Die Windows Phone Application Platform erlaubt es nicht, installierte Zertifikate an Apps auszugeben. Eine Mutual Authentication, bei der sich nicht nur der Server, sondern auch der Client mit einem SSL-Zertifikat ausweist, ist also nicht möglich.

Windows Phone 8 und Verschlüsselung

Wenn Sie unter Windows Phone 8 mit dem DPAPI verschlüsselte Daten auf der MicroSD-Karte speichern, denken Sie daran, dass diese Daten nur auf dem Smartphone entschlüsselt werden können, auf dem sie verschlüsselt wurden. Nur hier liegt der dazu benötigte Schlüssel vor. Es gelten also die gleichen Regeln wie bei der Speicherung von verschlüsselten Daten in der Cloud.

Web Services

Der Sicherheit von Web Services widmet Microsoft eine eigene Beschreibung, dabei gibt es eigentlich nichts wirklich anderes im Vergleich zur Nutzung mit einem Desktoprechner zu beachten [15]. Zur Authentifizierung stellt Windows Phone die Basic Authentication bereit. Da die Zugangsdaten dabei als Base64-kodierter Klartext übertragen werden, sollte die Verbindung über HTTPS abgesichert werden (was ein passendes Zertifikat voraussetzt, s. o.). Das Gleiche gilt für OAuth 1.0, da auch dabei die Zugangsdaten unverschlüsselt übertragen werden. Sollen Zugangsdaten auf dem Smartphone gespeichert werden, müssen sie mit der DPAPI geschützt werden. Wenn Sie einen Web Service implementieren wollen, der Push Notifications über den Microsoft Push Notification Service an Windows-Phone-Geräte sendet, sollten Sie eine Authentifizierung vorsehen [16]. Nicht authentifizierte Web Services sind auf 500 Benachrichtigungen pro Benutzer und Tag limitiert, für authentifizierte Web Services gibt es keine Einschränkung.

Die Capabilities

Wie schon erwähnt, werden die Fähigkeiten der individuellen Sandbox jeder App über die Capabilities festgelegt. Diese Festlegung erfolgt im Application Manifest [17] und dient zwei Zwecken. Erstens der Information des Benutzers über sicherheitsrelevante Anforderungen der App: Die App kann nur gekauft/installiert werden, wenn der Benutzer den Capabilities ausdrücklich zustimmt. Zweitens der Verkleinerung der Angriffsfläche: Jede Sandbox bekommt nur die Fähigkeiten, die die darin laufende App wirklich benötigt. Eine Liste der möglichen Capabilities finden Sie in Tabelle 1.

Wert Bedeutung
ID_CAP_APPOINTMENTS Zugriff auf die Appointment-Daten (Termine)
ID_CAP_CAMERA Zugriff auf die Kamera (nur für Mobilfunkbetreiber und OEMs, normale Entwickler nutzten stattdessen ID_CAP_ISV_CAMERA)
ID_CAP_CONTACTS Zugriff auf die Kontaktdaten
ID_CAP_GAMERSERVICES Interaktion mit Xbox LIVE APIs (wobei Daten an die Xbox übertragen werden)
ID_CAP_IDENTITY_DEVICE Zugriff auf gerätespezifische Informationen, wie die eindeutige Geräte-ID, Hersteller oder Modellname
ID_CAP_IDENTITY_USER Zugriff auf die Live ID, um den Benutzer eindeutig, aber anonym zu identifizieren
ID_CAP_ISV_CAMERA Zugriff auf die primäre/Frontkamera
ID_CAP_LOCATION Zugriff auf die Ortsbestimmung
ID_CAP_MEDIALIB Zugriff auf die Media Library
ID_CAP_MICROPHONE Zugriff auf das Mikrofon, eine Aufnahme ist möglich, ohne dass das angezeigt wird
ID_CAP_NETWORKING Zugriff auf das Netzwerk
ID_CAP_PHONEDIALER Durchführen von Telefongesprächen, ein geführtes Gespräch wird dem Benutzer u. U. nicht angezeigt
ID_CAP_PUSH_NOTIFICATION Empfang von Push Notifications
ID_CAP_SENSORS Zugriff auf die Gerätesensoren
ID_CAP_WEBBROWSERCOMPONENT Zugriff auf den Webbrowser
ID_HW_FRONTCAMERA Der Zugriff auf die Frontkamera wird benötigt; diese Capability dient nur dazu, den Benutzer ggf. zu informieren, dass bei Geräten ohne entsprechende Kamera einige Features der App nicht funktionieren

Beim Anlegen eines neuen Windows-Phone-Projekts werden der App automatisch alle verfügbaren Capabilities zugewiesen. Nicht benötigte Capabilities sollten Sie schon im Interesse einer minimierten Angriffsfläche löschen. Ihrer App kann es egal sein, ob Ihre Sandbox gar nicht genutzte Fähigkeiten besitzt oder nicht, im Fall eines erfolgreichen Angriffs freut sich der Angreifer aber über jede Möglichkeit, Schaden anzurichten.

Während der Prüfung der App vor der Veröffentlichung auf dem Marketplace werden die benötigten Capabilities durch ein Testprogramm ermittelt und das Manifest angepasst, nicht benötigte Capabilities werden aber nicht zwingend entfernt [18]. Für diese automatische Erstellung der Capabilities-Liste gibt es drei Ausnahmen (Tabelle 2). Die sind auch der Grund dafür, dass Sie ggf. nicht benötigte Capabilities selbst löschen und sich nicht auf die automatisch erstellte Capabilities-Liste verlassen sollten.

Wert Art der Ausnahme
ID_CAP_NETWORKING ID_HW_FRONTCAMERA Werden zum Manifest hinzugefügt, wenn sie benötigt werden, aber nicht entfernt, wenn sie beim Einreichen im Manifest vorhanden sind, aber nicht benötigt werden
ID_CAP_IDENTITY_DEVICE Wird zum Manifest hinzugefügt, wenn die Nutzung der Methode DeviceExtendedProperties.GetValue(„DeviceUniqueId“) erkannt wird und wenn sie beim Einreichen im Manifest vorhanden ist
Fazit

Die Entwicklung einer Smartphone-App unterscheidet sich aus Sicherheitssicht kaum von der Entwicklung einer Desktopanwendung. Da die Smartphone-Entwickler durch die Beschränkung auf Managed-Code zusätzlich unterstützt werden, lassen sich viele übliche C/C++-Fehler damit ja gar nicht machen. Mit Windows Phone 8 sollten die Unterschiede, zumindest soweit es um Metro-Apps geht, dann noch geringer werden.

Dipl.-Inform. Carsten Eilers ist freier Berater und Coach für IT-Sicherheit und technischen Datenschutz und Autor einer Vielzahl von Artikeln für verschiedene Magazine und Onlinemedien. Sie erreichen ihn unter www.ceilers-it.de, sein Blog finden Sie unter www.ceilers-news.de.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -