Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort
Vorwort
1 Hello iPhone
2 Die Reise nach iOS
3 Sehen und anfassen
4 Alles unter Kontrolle
5 Daten, Tabellen und Controller
6 Models, Layer, Animationen
7 Programmieren, aber sicher
8 Datenserialisierung und Internetzugriff
9 Multimedia
10 Jahrmarkt der Nützlichkeiten
Stichwort

Buch bestellen
Ihre Meinung?

Spacer
Apps programmieren für iPhone und iPad von Klaus M. Rodewig, Clemens Wagner
Das umfassende Handbuch
Buch: Apps programmieren für iPhone und iPad

Apps programmieren für iPhone und iPad
Rheinwerk Computing
1172 S., geb., mit DVD
49,90 Euro, ISBN 978-3-8362-2734-6
Pfeil 7 Programmieren, aber sicher
Pfeil 7.1 iOS und Hardware
Pfeil 7.2 Bedrohungen, Angriffe, Sicherheitslücken und Maßnahmen
Pfeil 7.2.1 Arten von Sicherheitslücken
Pfeil 7.3 Threat Modeling
Pfeil 7.3.1 Erstellen eines Datenflussdiagramms
Pfeil 7.3.2 STRIDE
Pfeil 7.3.3 Generische Designgrundsätze
Pfeil 7.3.4 Threat Modeling aus der Tube – das Microsoft SDL Threat Modeling Tool
Pfeil 7.4 Sichere Programmierung in der Praxis
Pfeil 7.4.1 Authentisierung
Pfeil 7.4.2 Keychain
Pfeil 7.4.3 Jailbreak-Erkennung
Pfeil 7.4.4 Verzeichnisse und Dateiattribute
Pfeil 7.4.5 Event-Handling
Pfeil 7.4.6 Screenshots
Pfeil 7.4.7 Sorgfältiger Umgang mit der Bildschirmsperre
Pfeil 7.4.8 Struktur und Ordnung im Sandkasten
Pfeil 7.4.9 UDID ist tot. Was nun?
Pfeil 7.4.10 Base64
Pfeil 7.5 iCloud
Pfeil 7.5.1 Denkanstöße
Pfeil 7.5.2 iCloud in der Praxis
Pfeil 7.5.3 Key-Value-Storage
Pfeil 7.5.4 Verschlüsselung (in der Cloud)

7Programmieren, aber sicherZur nächsten Überschrift

»Mobile wireless computers are like mobile pipeless bathrooms – portapotties. They will be common on vehicles, and to construction sites, and rock concerts. My advice is to wire up your home and stay there.«
– Robert Metcalfe, 1995

Das Thema IT-Sicherheit, das mittlerweile täglich in den Medien erwähnt wird, ist auch und gerade für Programmierer von Apps für das iPhone von besonderer Bedeutung. In den Zeiten, als Computer nicht mit dem Internet verbunden waren, mussten sich Programmierer in der Regel gar nicht mit der Sicherheit der von ihnen geschriebenen Programme befassen. Angriffe auf IT-Systeme sind zwar schon lange bekannt; ein Angreifer, der mangels Netzwerkverbindung aber keine Verbindung zu einem System aufbauen kann, wird schwerlich potenzielle Sicherheitslücken finden respektive ausnutzen können.

Dieser Zustand hat sich mit der immer weiter fortschreitenden Vernetzung von Systemen und der zunehmenden Digitalisierung unseres Lebens stark gewandelt. Es gibt kaum mehr ein System, das nicht mit dem Internet verbunden ist – auch im privaten Bereich. Das gilt insbesondere für Smartphones, also auch für das iPhone (und in gleichem Maße natürlich für das iPad und den iPod touch). Das iPhone gewinnt seine Funktionalität gerade durch die Verbindung zum Internet, dessen ständige Verfügbarkeit durch Mobilfunk-Flatrates und omnipräsente WLAN-Hotspots ermöglicht wird.

Das iPhone ist daher dem latenten Risiko eines Angriffs aus dem Internet ausgesetzt und überdies natürlich aufgrund der exponierten Lage auch Angriffen über die Trägermedien WLAN, Bluetooth und Mobilfunk. Während sich das Betriebssystem, also iOS, um die Bedrohung über die Trägermedien kümmern muss, haben Sie als App-Programmierer die Pflicht, die von Ihrer App verarbeiteten Daten entsprechend ihres Schutzbedarfs vor unbefugtem Zugriff zu schützen.

Regelmäßig kann man in einschlägigen Fachmagazinen Testberichte über Apps lesen, die mitunter fahrlässig mit den Daten ihrer Nutzer umgehen. In dem bekannten ct-Magazin aus dem Heise-Verlag stand 2011 in einem Test von Banking-Apps für das iPhone Folgendes zu einer der getesteten Apps:

Der Entwickler gestand freimütig ein, dass er lediglich Anwendungsprogrammierer, aber kein Sicherheitsexperte sei und iControl nur in seiner Freizeit am Wochenende weiterentwickle. Leider merkt man das auch am Resultat. Wer diesem Programm vertrauliche Daten anvertraut, handelt fast schon fahrlässig. [Anm.: http://www.heise.de/security/artikel/iPhone-Banking-Apps-im-Sicherheitscheck-1158091.html?artikelseite=2]

Apple gibt dem Programmierer mit verschiedenen Dokumenten eine gute Hilfestellung für die Entwicklung sicherer Apps. Der Secure Coding Guide [Anm.: https://developer.apple.com/library/mac/#documentation/security/Conceptual/SecureCodingGuide/Introduction.html] ist ein guter Einstieg in die sichere Programmierung, allerdings ist er für Einsteiger nicht »gut verdaulich«, und er deckt viele wichtige Aspekte der sicheren Programmierung unter iOS gar nicht ab.

Sichere Software lässt sich nicht durch das ungerichtete Implementieren generischer Sicherheitsmaßnahmen (wie z. B. Verschlüsselung oder Rollenkonzepte) herbeiführen. Vielmehr muss Sicherheit integraler Bestandteil des Entwicklungsprozesses sein und diesen durch alle relevanten Phasen begleiten. Die Anforderungsphase definiert den Schutzbedarf einer Software, und in der Designphase ist die Erstellung eines sicheren Designs das Fundament für die sichere Umsetzung, die anschließend in der Implementierungsphase stattfindet. Die dann im Betrieb notwendige Sicherheit ergibt sich durch die sichere Konfiguration sowie eine angemessene Wartung und die angemessene Reaktion auf bekannt werdende Sicherheitslücken.


Rheinwerk Computing - Zum Seitenanfang

7.1iOS und HardwareZur vorigen Überschrift

iOS besitzt verschiedene integrale Sicherheitsmechanismen, die das System, die darauf laufenden Apps und vor allen Dingen die Daten der Benutzer schützen sollen. Nebenbei schützen einige der Sicherheitsmechanismen auch das Geschäftsmodell von Apple, aber es ist ja eine alte Weisheit, dass lediglich der Tod umsonst ist.

Der rote Faden, der sich durch iOS zieht, ist die Verwendung von Zertifikaten. Das Betriebssystem führt keinen Code aus, der nicht mit einem von Apple ausgestellten Zertifikat signiert ist. Das beginnt sogar schon vor dem Start von iOS mit dem Bootloader, also dem Teil der Hardware, der für das Starten des Betriebssystems zuständig ist. Dieser Start geschieht in drei Stufen.

In der ersten Stufe prüft der Bootloader, der sich im Boot-ROM befindet (ein ROM – Read-only Memory – ist ein Speicher, der nur gelesen, nicht aber beschrieben werden kann), ob die nächste Stufe, der Low Level Bootloader (LLB), korrekt von Apple signiert ist. Ist das der Fall, übergibt der Bootloader der ersten Stufe die Kontrolle an den LLB, der wiederum die dritte Stufe (den sogenannten iBoot) überprüft und lädt, sofern iBoot ebenfalls ein gültiges und von Apple ausgestelltes Zertifikat besitzt.

iBoot führt dieselbe Prüfung beim iOS durch, das im Flash-Speicher liegt, und wenn er ein gültiges, d. h. von Apple signiertes iOS-System vorfindet, startet er dieses. Ein Fehler in der ersten Stufe des Bootvorgangs führt dazu, dass das iDevice in den DFU Mode umschaltet. DFU steht für Device Firmware Upgrade und ermöglicht das Aufspielen eines neuen iOS-Images über iTunes. Bei Fehlern in der zweiten oder dritten Stufe des Bootvorgangs schaltet das iDevice in den Recovery Mode, was Sie an dem iTunes-Symbol und dem USB-Kabel auf dem Display erkennen. Auch dieser Modus dient zum Installieren eines neuen iOS-Images per iTunes.

Ist das Betriebssystem einmal gestartet, überprüft der Kernel das sogenannte Mandatory Code Signing, also den auch zur Laufzeit des Systems unumgänglichen Zwang, dass jeder Code mit einem von Apple ausgestellten Zertifikat signiert sein muss. Es ist nicht möglich, ein beliebiges Stück Code zu nehmen und auf einem iDevice zur Ausführung zu bringen, so wie man es vom PC oder Mac kennt. Das ist auch der Grund, weswegen man als Programmierer für iOS-Apps Mitglied im iOS Developer Program bei Apple sein muss, denn nur darüber erhält man das Zertifikat, das man zum Signieren der Apps braucht, damit sie unter iOS lauffähig sind.

Das Mandatory Code Signing stellt zwei Dinge sicher:

  • Den Aktienkurs von Apple, denn wenn jeder App-Entwickler eine kostenpflichtige Mitgliedschaft erwerben muss, um Apps auf iDevices bringen zu können, wird das bei Apple für einen erklecklichen und kontinuierlichen Geldstrom sorgen.
  • Die Sicherheit des Systems und der darin befindlichen Daten. Der Zwang zur Signierung ist beileibe kein Allheilmittel, aber im Zusammenhang mit dem Umstand, dass Apps nur über den offiziellen App Store von Apple auf ein iDevice gelangen können, hat Apple die Latte für die Verteilung von Schadsoftware gegenüber Systemen ohne Mandatory Code Signing merklich höher gelegt. Es ist schlichtweg mehr Aufwand nötig, um dieses System zu umgehen, als einem PC-Benutzer ein Stück Schadsoftware unterzujubeln.

Natürlich besteht die abstrakte Gefahr, dass ein Angreifer einen Entwickler-Account kapert und über diesen Schadsoftware in den App Store einstellt, aber die Wahrscheinlichkeit seiner solchen Aktion ist aufgrund der Komplexität des gesamten Prozesses doch eher gering. Der App Store selbst stellt keinen nennenswerten Sicherheitsmechanismus im iOS-Biotop dar. Einer Studie [Anm.: »PiOS: Detecting Privacy Leaks in iOS Applications«, 2010, Egele et al.] der TU Wien aus dem Jahr 2010 zufolge lasen 55 % von 1.407 untersuchten Apps ungefragt Nutzerdaten wie das Adressbuch, die UDID oder Standortdaten vom Gerät aus und übermittelten diese Daten an fremde Server – 825 Apps kamen dabei aus dem offiziellen Apple App Store. Apples Reaktion bestand aus einem Verweis auf die Entwickler der Apps. Der Review-Prozess für den App Store stellt daher kein Security Gate im Sinne sicherer Softwareentwicklung dar.

Ist eine App von iOS als korrekt erkannt worden (besitzt sie also ein gültiges Zertifikat), startet iOS diese App und sperrt sie umgehend in einen virtuellen Käfig, die Sandbox, zu Deutsch Sandkasten. Der Sandkasten besteht aus Sicht einer App darin, dass die App einen eigenen Bereich im Dateisystem zugewiesen bekommt, in dem sie sich austoben darf – so wie in einem echten Sandkasten eben. Innerhalb dieses Bereichs hat die App Schreibrechte; außerhalb dieses Bereiches kann eine App nur lesend auf einige Verzeichnisse und Dateien zugreifen, und der lesende Zugriff auf Systemdateien ist ganz unterbunden. Ebenso ist der lesende Zugriff auf die Sandkästen anderer Apps verboten.

Da alle Daten einer App innerhalb des eigenen Sandkastens liegen, stellt das Sandboxing somit sicher, dass eine App keine Daten anderer Apps auslesen oder manipulieren kann. Innerhalb einer Sandbox gibt es Standardverzeichnisse für verschiedene Aufgaben. In Abschnitt 7.4.4, »Verzeichnisse und Dateiattribute«, lernen Sie diese Verzeichnisse näher kennen.

Beim Löschen einer App löscht iOS auch die dazugehörige Sandbox im Dateisystem, so dass es durch die Installation von Apps auch nicht zu dem von einigen Desktop-Betriebssystemen bekannten Phänomen kommt, dass Programme Dateien und Daten an globalen Orten und in Systemverzeichnissen ablegen, wodurch das Gesamtsystem im Laufe der Zeit immer unübersichtlicher wird.

Der Zugriff auf globale Ressourcen (wie z. B. Kalender, Fotos oder das Adressbuch) ist ausschließlich über die von iOS für diesen Zweck bereitgestellten API-Aufrufe möglich. Der Zugriff über das Dateisystem (z. B. auf die Datenbankdatei des Kalenders) wird vom Sandboxing verhindert.

Seit iOS 4 ist Multitasking möglich, d. h., das Betätigen des Home-Buttons auf einem iDevice führt nicht mehr zum Beenden einer App. Stattdessen geht die App in einen Hintergrund-Zustand über, in dem sie einige genau festgelegte Aktionen ausführen darf. Erst wenn ein Benutzer die App bewusst beendet oder der Speicher auf dem iDevice knapp wird und iOS anfängt, Apps aus dem Speicher zu werfen, wird die App beendet.

Auf einer Ebene, die für den App-Programmierer kaum von Belang, für einen Angreifer aber sehr interessant ist – nämlich wenn es um den manipulierenden Zugriff auf Speicher geht –, besitzt iOS seit der Version 4.3 zwei Schutzmechanismen. Der eine besteht aus der Verwendung von Address Space Layout Randomization (ASLR). Darunter versteht man die zufällige Anordnung des Speichers, um gezielte Angriffe zu verhindern. Ein Angreifer, der sich Zugriff auf den Speicher verschaffen kann und genau weiß, an welcher Stelle sich welche Bibliotheken und Funktionen befinden, kann diese gezielt angreifen. ASLR unter iOS weist den Systembibliotheken bei jedem Systemstart neue Adressen im Speicher zu.

Die System-Apps von iOS (also z. B. Safari, Mail, Kalender) bekommen bei jedem Start einen zufälligen Speicherbereich zugewiesen. So wie jeder Sicherheitsmechanismus lässt sich auch ASLR umgehen; es erhöht allerdings den Aufwand für einen erfolgreichen Angriff gegen iOS. Als App-Programmierer haben Sie mit ASLR grundsätzlich nichts zu tun – Xcode sorgt automatisch dafür, dass eine App mit ASLR-Unterstützung kompiliert wird.

Der andere Schutzmechanismus für den Speicher besteht darin, dass iOS die Möglichkeit der in den iDevices verbauten ARM-Prozessoren verwendet, Speicherseiten als »nicht ausführbar« zu markieren, das sogenannte NX-Bit. Die ARM-Architektur besitzt wie die vom Mac bekannte Intel-Architektur den Nachteil, dass sich Daten und Instruktionen im selben Speicher befinden. Dies ist der Von-Neumann-Architektur geschuldet, der Architektur, nach der die ARM-Prozessoren gestaltet sind. John von Neumann, der Erfinder dieser Architektur (allerdings nicht der ARM-Architektur!) und ein Pionier der Informatik, hat für seine Architektur nur eine Art von Speicher vorgesehen, so dass Daten und Instruktionen zwingend im selben Speicher liegen müssen.

Bei dieser Speicherarchitektur besteht die Gefahr darin, dass ein Angreifer ausführbaren Code (Instruktionen) an Speicherstellen schafft, an denen eigentlich nur Daten liegen sollten. Gelingt es ihm dann, diese Speicherstellen im Programmfluss anzuspringen, kann er seinen Code zur Ausführung bringen. [Anm.: Das Gegenmodell zur Von-Neumann-Architektur ist die Harvard-Architektur. Die von Apple früher verbauten PowerPC-Prozessoren basierten auf dieser Architektur.] Um dieses architektonische Sicherheitsproblem zu minimieren, verfügen moderne Prozessoren über das NX-Bit, mit dem das Betriebssystem Speicherstellen, an denen Daten liegen, als nicht ausführbar markiert. Ein Angreifer kann über diese Speicherstellen dann keinen Code ausführen, selbst wenn er welchen hineinschreiben kann.

Auf der Hardwareseite verfügen neuere iDevices ebenfalls über einen Sicherheitsmechanismus. Seit dem iPhone 3GS gibt es einen transparenten, in Hardware gegossenen AES-256- und SHA1-Beschleuniger. Damit lassen sich symmetrische Ver- und Entschlüsselung sowie Hash-Operationen schnell und ressourcensparend durchführen.

Jedes iDevice besitzt eine weltweit eindeutige Geräte-ID und eine ebenso eindeutige Gruppen-ID (UDID und GID). Beide Daten sind für iOS und damit für den App-Entwickler nicht zugänglich, sondern dienen dem AES-Beschleuniger als Parameter bei der Verschlüsselung, die Sie in Abschnitt 7.4.2, »Keychain«, kennenlernen werden.

iOS ist ein komplexes Betriebssystem. Mit der Komplexität eines Systems steigen die darin enthaltenen Fehler und damit auch die Sicherheitslücken, denn eine Sicherheitslücke ist nichts anderes als ein Fehler, den ein Angreifer ausnutzen kann, um Aktionen auszuführen, zu denen er nicht berechtigt ist. iOS weist, wie die Changelogs für neue iOS-Versionen regelmäßig zeigen, in jeder Version eine Vielzahl von schwerwiegenden Sicherheitslücken auf. Es ist bis heute keine Lösung bekannt, Software sicher zu programmieren. Es gibt lediglich einige Bemühungen, von denen diejenige, den Entwicklungsprozess mit Sicherheitselementen anzureichern, bisher die vielversprechendste ist.

Verschiedenen Studien [Anm.: »Fehler in Software«, Dr.-Ing. Matthias Werner, TU Chemnitz 2007] zufolge enthält Software auf 100 Zeilen Code einen Fehler; es ist also 1 % der Code-Zeilen fehlerhaft. Der Umfang von iOS ist zwar unbekannt, aber wenn wir zum Vergleich den Linux-Kernel heranziehen, der 2003 bereits aus knapp 6.000.000 Zeilen Code bestand, werden die Dimensionen deutlich, in denen sich ein komplexes Betriebssystem wie iOS bewegt. 6.000.000 Zeilen Code enthalten statistisch 60.000 Fehler, von denen ein Teil naturgemäß Sicherheitslücken öffnet.

Die in iOS enthaltenen Sicherheitslücken führen zu einem bekannten Problem: Findige Hacker schaffen es immer wieder, durch Sicherheitslücken das Betriebssystem seiner wichtigsten Sicherheitsfunktionen, vor allem Sandboxing und Code Signing, zu berauben (Jailbreak). Dies sollte ein App-Entwickler wissen und – je nach Schutzbedarf seiner App – entsprechende Maßnahmen treffen. Wie Sie einen Jailbreak erkennen und welche Maßnahmen möglich sind, zeigt Abschnitt 7.4.3, »Jailbreak-Erkennung«.

Abgesehen von den oben genannten Sicherheitsmechanismen, von denen hauptsächlich Codesignierung und Sandboxing für den App-Programmierer von näherem Interesse sind, verfügt iOS über ein von Mac OS X geerbtes zentrales Sicherheitselement: die Keychain. Die Keychain ist eine verschlüsselte Datenbank, in der iOS Zugangsdaten und Zertifikate ablegt und auf die eine App über entsprechende API-Aufrufe ebenfalls zugreifen kann, um sensible Daten sicher abzulegen.

Keychain oder Schlüsselbund

Im deutschen Sprachgebrauch (auf deutschen Mac-Rechnern) heißt die Keychain Schlüsselbund. Unter iOS arbeitet die Keychain im Hintergrund und ist lediglich für App-Programmierer relevant.

Da diese ohnehin mit der englischsprachigen API und deren ebenfalls englischsprachiger Dokumentation arbeiten, verzichten wir auf die Verwendung des deutschen Begriffs Schlüsselbund und nennen das Kind bei seinem englischen Namen: Keychain.

Den Umgang mit der Keychain zeigen wir im gleichnamigen Abschnitt 7.4.2. Dort erläutern wir ebenfalls, wie Sie die von einer App erzeugten Dateien über den Benutzercode gegen unbefugten Zugriff schützen können.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück




Copyright © Rheinwerk Verlag GmbH, Bonn 2014
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Rheinwerk Computing]

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de


  Zum Katalog
Zum Katalog: Apps programmieren für iPhone und iPad






Apps programmieren für iPhone und iPad
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Apps programmieren für iPhone und iPad






Apps programmieren für iPhone und iPad


Zum Katalog: Einstieg in Objective-C 2.0 und Cocoa






Einstieg in Objective-C 2.0 und Cocoa


Zum Katalog: Spieleprogrammierung mit Android Studio






Spieleprogrammierung mit Android Studio


Zum Katalog: Android 5






Android 5


Zum Katalog: iPhone und iPad-Apps entwickeln






iPhone und iPad-Apps entwickeln


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo