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

Inhaltsverzeichnis
Geleitwort des Gutachters
Vorwort
1 Einführung
2 Einstieg in die Praxis
3 Aufwachen – analoger Wecker
4 Daten, Tabellen und Controller
5 Animationen und Layer
6 Programmieren, aber sicher
7 Jahrmarkt der Nützlichkeiten
A Die Buch-DVD
Stichwort

Download:
- ZIP, ca. 23,6 MB
Buch bestellen
Ihre Meinung?

Spacer
Apps entwickeln für iPhone und iPad von Klaus M. Rodewig, Clemens Wagner
Das Praxisbuch
Buch: Apps entwickeln für iPhone und iPad

Apps entwickeln für iPhone und iPad
geb., mit DVD
515 S., 34,90 Euro
Galileo Computing
ISBN 978-3-8362-1463-6
Pfeil 6 Programmieren, aber sicher
Pfeil 6.1 Sicherheitsmechanismen von iOS
Pfeil 6.2 Bedrohungen, Angriffe, Sicherheitslücken und Maßnahmen
Pfeil 6.2.1 Arten von Sicherheitslücken
Pfeil 6.3 Threat Modeling
Pfeil 6.3.1 Erstellen eines Datenflussdiagramms
Pfeil 6.3.2 STRIDE
Pfeil 6.3.3 Generische Design-Grundsätze
Pfeil 6.3.4 Threat Modeling aus der Tube – das Microsoft SDL Threat Modeling Tool
Pfeil 6.4 Sicherer Entwicklungszyklus
Pfeil 6.4.1 Awareness
Pfeil 6.4.2 Umgebung
Pfeil 6.4.3 Training
Pfeil 6.4.4 Dokumentation
Pfeil 6.4.5 Requirements
Pfeil 6.4.6 Design
Pfeil 6.4.7 Implementierung
Pfeil 6.4.8 Security-Testing
Pfeil 6.4.9 Deployment
Pfeil 6.4.10 Security Response
Pfeil 6.4.11 Sicherheitsmetriken
Pfeil 6.4.12 Abschließende Bemerkung
Pfeil 6.5 Sicherheit in der iOS-API
Pfeil 6.5.1 Keychain
Pfeil 6.5.2 Dateiattribute
Pfeil 6.5.3 Jailbreak-Erkennung
Pfeil 6.5.4 Event-Handling

»If you spend more on coffee than on IT security, you will be hacked. What's more, you deserve to be hacked.«
– Richard Clarke, White House Cybersecurity Advisor, ret.

6 Programmieren, aber sicherZur nächsten Überschrift

Das Thema IT-Sicherheit, das mittlerweile zum Tagesgespräch in den Medien gehört, ist auch und insbesondere für Programmierer von Apps für das iPhone von besonderer Bedeutung. Zu Zeiten, in denen Computer nicht mit dem Internet verbunden waren, mussten sich Programmierer in der Regel gar nicht mit der Sicherheit der von ihnen programmierten 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.

Dies hat sich seit 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, deren ständige Verfügbarkeit durch Mobilfunk-Flatrates und omnipräsente WLAN-Hotspots ermöglicht wird.

Dadurch liegen für das iPhone zwei grundsätzliche Bedrohungsszenarien vor: Der Angriff aus dem Netz auf das Gerät und das (unbefugte) Abgreifen von Daten vom Gerät. Hinzu kommt neben dem Aspekt der Bedrohung über das Netzwerk die Tatsache, dass ein iPhone ein großer Datenspeicher ist, der in der Regel mindestens personenbezogene Daten beinhaltet, wenn nicht sogar sensible Firmen- oder Zugangsdaten. Der effiziente Schutz dieser Daten ist neben der rechtlichen Verpflichtung eine Grundanforderung an eine App. Regelmäßig kann man in einschlägigen Fachmagazinen Testberichte über Apps lesen, die mitunter fahrlässig mit den Daten ihrer Nutzer umgehen. Das bekannte c't-Magazin aus dem Heise-Verlag hat 2011 in einem Test von Banking-Apps für das iPhone zu einer der getesteten Apps die folgende Aussage getroffen:

»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 [25](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 ist ein guter Einstieg in die sichere Programmierung.

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, in der Designphase ist die Erstellung eines sicheren Designs das Fundament der in der Implementierungsphase stattfindenden sicheren Umsetzung. 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. Abschnitt 6.4 gibt einen Einblick in die elementaren Bestandteile eines sicheren Software-Entwicklungszyklus.


Galileo Computing - Zum Seitenanfang

6.1 Sicherheitsmechanismen von iOSZur vorigen Überschrift

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 unbefugte Aktionen auszuführen. iOS weist immer wieder, wie die Changelogs für neue iOS-Versionen regelmäßig zeigen, eine Vielzahl von schwerwiegenden Sicherheitslücken auf. Allein das Update auf iOS 4.3 hat 59 Sicherheitslücken geschlossen. [26](http://support.apple.com/kb/HT4564) Der größte Teil davon waren kritische Sicherheitslücken, die einem Angreifer das Ausführen von Code auf dem iPhone erlaubt hätten.

Es ist nicht die Absicht der Autoren, die Sicherheit von iOS zu bewerten, allerdings muss sich der Programmierer von Apps Gedanken über die Sicherheit der von seinen Apps verarbeiteten Daten vor dem Hintergrund eines Betriebssystems machen, das regelmäßig durch schwerwiegende Sicherheitslücken auffällt. Dies gilt natürlich nicht ausschließlich für iOS, denn jedes System dieser Größe und Komplexität weist Sicherheitslücken auf. Es ist auch bis heute keine Lösung bekannt, um Software sicher zu programmieren. Es gibt lediglich einige Bemühungen, von denen diejenige, den Entwicklungsprozess mit Sicherheitselementen anzureichern, bisher die vielversprechendste ist.

Verschiedenen Studien [27](»Fehler in Software«, Dr.-Ing. Matthias Werner, TU Chemnitz 2007) zufolge enthält Software auf 100 Zeilen Code einen Fehler, es sind also 1 % der Codezeilen fehlerhaft. Der Umfang von iOS ist zwar unbekannt, aber wenn man zum Vergleich den Linux-Kernel heranzieht, 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 zu berauben (Jailbreak). Dies sollte ein App-Entwickler wissen und – je nach Schutzbedarf seiner App – entsprechende Maßnahmen treffen. Wie man einen Jailbreak erkennt und welche Maßnahmen möglich sind, zeigt Abschnitt 6.5.3.

iOS bringt verschiedene Mechanismen mit, um die Sicherheit des Systems zu gewährleisten. Jede App läuft in einem eigenen virtuellen Raum. Dies bezieht sich sowohl auf das Dateisystem als auch auf den Speicher. Dieses als Sandboxing bezeichnete Prinzip verhindert, dass Apps auf Daten und Dateien anderer Apps zugreifen können. Eine App kann sich in ihrer eigenen Sandbox nach Belieben austoben, ohne damit Einfluss auf andere Apps oder das Betriebssystem zu nehmen.

Beim Löschen einer App löscht iOS auch die dazugehörige Sandbox im Dateisystem, sodass 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 Systemverzeichnissen ablegen, wodurch das Gesamtsystem im Laufe der Zeit immer unübersichtlicher wird.

Wie in Kapitel 1 beschrieben wurde, ist zum Ausführen einer App auf einem i-Gerät ein Entwickler-Zertifikat notwendig. iOS führt ausschließlich Code aus, der mit einem gültigen Zertifikat versehen ist. Dieser Zwang zur Code-Signierung ist ein weiteres Sicherheitsmerkmal von iOS. Damit verhindert Apple, dass Code aus nicht vertrauenswürdiger Quelle auf ein Gerät kommt und dort Schaden anrichtet. Ein Zertifikat ist immer an einen Entwickler-Account im iPhone Developer Program gekoppelt, der wiederum an eine Kreditkarte gekoppelt ist (das Zertifikat ist ja nur im kostenpflichtigen Account enthalten).

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 ist aufgrund der Komplexität des gesamten Prozesses doch eher gering. Der App Store selber stellt keinen nennenswerten Sicherheitsmechanismus im iOS-Biotop dar. Einer Studie [28](»PiOS: Detecting Privacy Leaks in iOS Applications«, 2010, Egele et al.) der TU Wien aus dem Jahr 2010 zufolge haben 55 % von 1407 untersuchten Apps ungefragt Nutzerdaten wie das Adressbuch, die UDID oder Standortdaten vom Gerät ausgelesen und an fremde Server übermittelt – 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 Software-Entwicklung dar.

Neben den globalen Mechanismen Sandboxing und Signierung beinhaltet iOS unter der Haube noch weitere Sicherungsmechanismen. So laufen Apps alle unter dem Benutzerkonto mobile. Schreibzugriff auf Systemverzeichnisse hat ausschließlich der Benutzer root. iOS verwendet also die Unix-eigene Separierung von Benutzerrechten, verzichtet aber darauf, jeder App einen eigenen Benutzerkontext zu geben, wie es z. B. Android macht. Das führt dazu, dass beim Ausfall der zentralen Sandbox-Sicherheit jede App auf die Daten der anderen Apps zugreifen kann – was nicht mehr state of the art ist.

Überdies ist befremdlicherweise das Passwort für den Benutzer root unter iOS auf den Wert alpine gesetzt. Dieses Passwort ist aufgrund seiner Verbreitung im Internet weder geheim, noch genügt es den Ansprüchen an ein sicheres Passwort (zu kurz, zu einfach). Die Trennung von App-Benutzer und Administration bietet nichtsdestotrotz auf einem Gerät ohne Jailbreak einen robusten Grundschutz.

Um die aus setuid-Programmen resultierenden, hinlänglich bekannten Sicherheitslücken zu vermeiden, gibt es in iOS keine Dateien mit gesetztem setuid-Bit. Darüber hinaus sind die Syscalls sys_setreuid und sys_setreguid aus dem iOS-Kernel entfernt.

Stack und Heap sind unter iOS mit dem NX-Flag geschützt (non executable). Darüber hinaus hat Apple mit iOS 4.3 die Address Space Layout Randomization (ASLR) eingeführt, die den Speicher zufällig anordnet und auf diese Weise Angriffe über die typische C-Schwachstelle des Buffer Overflows verhindern soll. Auch hier gilt: Das Umgehen dieser Mechanismen ist möglich, ASLR lässt sich über die in Mode gekommene Technik des Sprayings umgehen, allerdings legt beides die Latte für einen erfolgreichen Angriff merklich höher.

Abgesehen von den vorstehenden Sicherheitsmechanismen, von denen hauptsächlich Code-Signierung 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 vs. 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 englischsprachigen Dokumentation arbeiten, verzichten wir auf der Verwendung des deutschen Begriffs Schlüsselbund und nennen das Kind bei seinem englischen Namen: Keychain.

Den Umgang mit der Keychain zeigt Abschnitt 6.5. Dieser Abschnitt zeigt ebenfalls, wie sich von einer App erzeugte Dateien über den Benutzercode gegen unbefugten Zugriff schützen lassen.



Ihr Kommentar

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







<< zurück
  Zum Katalog
Zum Katalog: Apps entwickeln für iPhone und iPad





Apps entwickeln für iPhone und iPad
Jetzt bestellen


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

 Buchempfehlungen
Objective-C 2.0 & Cocoa





 Objective-C 2.0
 Cocoa


Zum Katalog: Mac OS X Lion






 Mac OS X Lion


Zum Katalog: Mac OS X und UNIX






 Mac OS X
 und UNIX


Zum Katalog: Android 3






 Android 3


Zum Katalog: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Katalog: CSS






 CSS


Zum Katalog: jQuery






 jQuery


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2011
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.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de