Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. iOS SDK

Sichern der Kommunikation unter iOS

by
Read Time:16 minsLanguages:

German (Deutsch) translation by Valentina (you can also view the original English article)

Mobile Sicherheit ist ein heißes Thema geworden. Bei jeder App, die remote kommuniziert, ist es wichtig, die Sicherheit der Benutzerinformationen zu berücksichtigen, die über ein Netzwerk gesendet werden. In diesem Beitrag lernen Sie die aktuellen Best Practices zum Sichern der Kommunikation Ihrer iOS-App in Swift kennen.

Verwenden Sie HTTPS

Erwägen Sie bei der Entwicklung Ihrer App, Netzwerkanforderungen auf diejenigen zu beschränken, die unbedingt erforderlich sind. Stellen Sie bei diesen Anforderungen sicher, dass sie über HTTPS und nicht über HTTP erfolgen. Dies schützt die Daten Ihres Benutzers vor "Man-in-the-Middle-Angriffen", bei denen ein anderer Computer im Netzwerk als Relay für Ihre Verbindung fungiert, aber mithört oder ändert die Daten, die es weitergibt. Der Trend in den letzten Jahren geht dahin, dass alle Verbindungen über HTTPS hergestellt werden. Zum Glück erzwingen neuere Versionen von Xcode dies bereits.

Um eine einfache HTTPS-Anfrage unter iOS zu erstellen, müssen wir lediglich "s" an den Abschnitt "http" der URL anhängen. Solange der Host HTTPS unterstützt und über gültige Zertifikate verfügt, erhalten wir eine sichere Verbindung. Dies funktioniert für APIs wie URLSession, NSURLConnection und CFNetwork sowie für beliebte Bibliotheken von Drittanbietern wie AFNetworking.

App Transport Sicherheit

Im Laufe der Jahre hatte HTTPS mehrere Angriffe dagegen. Da es wichtig ist, HTTPS korrekt zu konfiguriren, hat Apple App Transport Security (kurz ATS) erstellt. ATS stellt sicher, dass die Netzwerkverbindungen Ihrer App branchenübliche Protokolle verwenden, damit Sie Benutzerdaten nicht versehentlich unsicher senden. Die gute Nachricht ist, dass ATS standardmäßig für Apps aktiviert ist, die mit aktuellen Versionen von Xcode erstellt wurden.

ATS ist ab iOS 9 und OS X El Capitan verfügbar. Aktuelle Apps im Store erfordern nicht plötzlich ATS, aber Apps, die für neuere Versionen von Xcode und dessen SDKs erstellt wurden, sind standardmäßig aktiviert. Einige der von ATS erzwungenen Best Practices umfassen die Verwendung von TLS Version 1.2 oder höher, die Weiterleitungsgeheimnis durch ECDHE-Schlüsselaustausch, die AES-128-Verschlüsselung und die Verwendung von mindestens SHA-2-Zertifikaten.

Es ist wichtig zu beachten, dass ATS zwar automatisch aktiviert wird, jedoch nicht unbedingt bedeutet, dass ATS in Ihrer App erzwungen wird. ATS arbeitet mit den Basisklassen wie URLSession und NSURLConnection sowie mit streambasierten CFNetwork-Schnittstellen. ATS wird nicht für Netzwerkschnittstellen auf niedrigerer Ebene wie Raw-Sockets, CFNetwork-Sockets oder Bibliotheken von Drittanbietern erzwungen, die diese Aufrufe auf niedrigerer Ebene verwenden würden. Wenn Sie also ein Netzwerk auf niedriger Ebene verwenden, müssen Sie darauf achten, die Best Practices von ATS manuell zu implementieren.

ATS-Ausnahmen

Da ATS die Verwendung von HTTPS und anderen sicheren Protokollen erzwingt, fragen Sie sich möglicherweise, ob Sie weiterhin Netzwerkverbindungen herstellen können, die HTTPS nicht unterstützen, z. B. wenn Sie Bilder aus einem CDN-Cache herunterladen. Keine Sorge, Sie können die ATS-Einstellungen für bestimmte Domänen in der Plist-Datei Ihres Projekts steuern. Suchen Sie in Xcode Ihre Datei info.plist, klicken Sie mit der rechten Maustaste darauf und wählen Sie Öffnen als > Quellcode.

Sie finden einen Abschnitt namens NSAppTransportSecurity. Wenn es nicht vorhanden ist, können Sie den Code selbst hinzufügen. Das Format ist wie folgt.

Auf diese Weise können Sie die ATS-Einstellungen für alle Netzwerkverbindungen ändern. Einige der allgemeinen Einstellungen sind wie folgt:

  • NSAllowsArbitraryLoads: Deaktiviert ATS. Benutze das nicht! Zukünftige Versionen von Xcode entfernen diesen Schlüssel.
  • NSAllowsArbitraryLoadsForMedia: Ermöglicht das Laden von Medien ohne ATS-Einschränkungen für das AV Foundation-Framework. Sie sollten unsichere Ladevorgänge nur zulassen, wenn Ihre Medien bereits auf andere Weise verschlüsselt sind. (Verfügbar unter iOS 10 und macOS 10.12.)
  • NSAllowsArbitraryLoadsInWebContent: Kann verwendet werden, um die ATS-Einschränkungen für Webansichtsobjekte in Ihrer App zu deaktivieren. Denken Sie zuerst nach, bevor Sie dies deaktivieren, da Benutzer damit beliebige unsichere Inhalte in Ihre App laden können. (Verfügbar unter iOS 10 und macOS 10.12.)
  • NSAllowsLocalNetworking: Hiermit können lokale Netzwerkressourcen ohne ATS-Einschränkungen geladen werden. (Verfügbar unter iOS 10 und macOS 10.12.)

Mit dem NSExceptionDomains-Wörterbuch können Sie Einstellungen für bestimmte Domänen festlegen. Hier finden Sie eine Beschreibung einiger nützlicher Schlüssel, die Sie für Ihre Domain verwenden können:

  • NSExceptionAllowsInsecureHTTPLoads: Ermöglicht der spezifischen Domäne, Nicht-HTTPS-Verbindungen zu verwenden.
  • NSIncludesSubdomains: Gibt an, ob die aktuellen Regeln an Subdomains weitergegeben werden.
  • NSExceptionMinimumTLSVersion: Wird verwendet, um ältere, weniger sichere TLS-Versionen anzugeben, die zulässig sind.

Perfekte Geheimhaltung

Während verschlüsselter Datenverkehr nicht lesbar ist, wird er möglicherweise trotzdem gespeichert. Wenn der private Schlüssel, der zum Verschlüsseln dieses Datenverkehrs verwendet wird, in Zukunft gefährdet ist, kann der Schlüssel zum Lesen des gesamten zuvor gespeicherten Datenverkehrs verwendet werden.

Um diese Art von Kompromissen zu vermeiden, generiert Perfect Forward Secrecy (PFS) einen Sitzungsschlüssel, der für jede Kommunikationssitzung eindeutig ist. Wenn der Schlüssel für eine bestimmte Sitzung kompromittiert wird, werden keine Daten aus anderen Sitzungen kompromittiert. ATS implementiert standardmäßig PFS, und Sie können diese Funktion mit dem Plist-Schlüssel NSExceptionRequiresForwardSecrecy steuern. Durch Deaktivieren dieser Option werden TLS-Chiffren aktiviert, die keine perfekte Vorwärtsgeheimnis unterstützen.

Zertifikatstransparenz

Die Zertifikatstransparenz ist ein neuer Standard, mit dem die beim Einrichten einer HTTPS-Verbindung vorgelegten Zertifikate überprüft oder geprüft werden können.

Wenn Ihr Host ein HTTPS-Zertifikat einrichtet, wird es von einer sogenannten Zertifizierungsstelle (Certificate Authority, CA) ausgestellt. Die Zertifikatstransparenz zielt darauf ab, nahezu in Echtzeit zu überwachen, um festzustellen, ob ein Zertifikat böswillig ausgestellt wurde oder von einer gefährdeten Zertifizierungsstelle ausgestellt wurde.

Wenn ein Zertifikat ausgestellt wird, muss die Zertifizierungsstelle das Zertifikat an eine Reihe von Nur-Anhängen-Zertifikatsprotokollen senden, die später vom Client überprüft und vom Eigentümer der Domäne überprüft werden können. Das Zertifikat muss in mindestens zwei Protokollen vorhanden sein, damit das Zertifikat gültig ist.

Der Plist-Schlüssel für diese Funktion lautet NSRequiresCertificateTransparency. Durch Aktivieren dieser Option wird die Zertifikatstransparenz erzwungen. Dies ist unter iOS 10 und MacOS 10.12 und höher verfügbar.

Anheften von Zertifikaten und öffentlichen Schlüsseln

Wenn Sie ein Zertifikat zur Verwendung von HTTPS auf Ihrem Server erwerben, gilt dieses Zertifikat als legitim, da es mit einem Zertifikat einer zwischengeschalteten Zertifizierungsstelle signiert ist. Dieses von der Zwischenbehörde verwendete Zertifikat kann wiederum von einer anderen Zwischenbehörde usw. signiert werden, sofern das letzte Zertifikat von einer vertrauenswürdigen Stammzertifizierungsstelle signiert ist.

Wenn eine HTTPS-Verbindung hergestellt wird, werden diese Zertifikate dem Client vorgelegt. Diese Vertrauenskette wird ausgewertet, um sicherzustellen, dass die Zertifikate von einer Zertifizierungsstelle korrekt signiert sind, der iOS bereits vertraut. (Es gibt Möglichkeiten, diese Prüfung zu umgehen und Ihr eigenes selbstsigniertes Zertifikat zum Testen zu akzeptieren. Tun Sie dies jedoch nicht in einer Produktionsumgebung.)

Wenn eines der Zertifikate in der Vertrauenskette nicht gültig ist, gilt das gesamte Zertifikat als ungültig und Ihre Daten werden nicht über die nicht vertrauenswürdige Verbindung gesendet. Dies ist zwar ein gutes System, aber nicht kinderleicht. Es gibt verschiedene Schwachstellen, die dazu führen können, dass iOS dem Zertifikat eines Angreifers anstelle eines rechtmäßig signierten Zertifikats vertraut.

Beispielsweise können Interception-Proxys ein vertrauenswürdiges Zwischenzertifikat besitzen. Ein Reverse Engineer kann iOS manuell anweisen, sein eigenes Zertifikat zu akzeptieren. Darüber hinaus hat die Richtlinie eines Unternehmens das Gerät möglicherweise so bereitgestellt, dass es sein eigenes Zertifikat akzeptiert. All dies führt dazu, dass Sie einen "Mann in der Mitte" -Angriff auf Ihren Datenverkehr ausführen und ihn lesen können. Durch das Anheften von Zertifikaten wird jedoch verhindert, dass für alle diese Szenarien Verbindungen hergestellt werden.

Das Anheften von Zertifikaten hilft, indem das Serverzertifikat mit einer Kopie des erwarteten Zertifikats verglichen wird.

Um das Fixieren zu implementieren, muss der folgende Delegat implementiert werden. Verwenden Sie für URLSession Folgendes:

Oder für NSURLConnection können Sie Folgendes verwenden:

Mit beiden Methoden können Sie ein SecTrust-Objekt von Challenge.protectionSpace.serverTrust abrufen. Da wir die Authentifizierungsdelegierten überschreiben, müssen wir jetzt explizit die Funktion aufrufen, die die soeben besprochenen Standardprüfungen der Zertifikatskette durchführt. Rufen Sie dazu die Funktion SecTrustEvaluate auf. Dann können wir das Zertifikat des Servers mit einem erwarteten vergleichen.

Hier ist eine Beispielimplementierung.

Um diesen Code zu verwenden, legen Sie beim Erstellen Ihrer Verbindung den Delegaten der URLSession fest.

Stellen Sie sicher, dass das Zertifikat in Ihrem App-Bundle enthalten ist. Wenn es sich bei Ihrem Zertifikat um eine PEM-Datei handelt, müssen Sie es im macOS-Terminal in eine CER-Datei konvertieren:

openssl x509 -inform PEM -in mycert.pem -outform DER -out certificate.cer

Wenn das Zertifikat von einem Angreifer geändert wird, erkennt Ihre App es und weigert sich, die Verbindung herzustellen.

Beachten Sie, dass einige Bibliotheken von Drittanbietern wie AFNetworking das Pinnen bereits unterstützen.

Desinfektion und Validierung

Bei all den bisherigen Schutzmaßnahmen sollten Ihre Verbindungen gegen Angriffe von Männern in der Mitte ziemlich sicher sein. Trotzdem ist es eine wichtige Regel in Bezug auf die Netzwerkkommunikation, den empfangenen Daten niemals blind zu vertrauen. Tatsächlich ist es eine gute Programmierpraxis, vertraglich zu entwerfen. Die Ein- und Ausgänge Ihrer Methoden haben einen Vertrag, der bestimmte Schnittstellenerwartungen definiert. Wenn die Schnittstelle angibt, dass eine NSNumber zurückgegeben wird, sollte dies der Fall sein. Wenn Ihr Server eine Zeichenfolge mit maximal 24 Zeichen erwartet, stellen Sie sicher, dass die Schnittstelle nur bis zu 24 Zeichen zurückgibt.

Dies hilft, unschuldige Fehler zu vermeiden, aber was noch wichtiger ist, es kann auch die Wahrscheinlichkeit verschiedener Angriffe auf Injektionen und Speicherbeschädigungen verringern. Gängige Parser wie die JSONSerialization-Klasse konvertieren Text in Swift-Datentypen, in denen diese Testarten durchgeführt werden können.

Andere Parser arbeiten möglicherweise mit Objective-C-äquivalenten Objekten. Hier können Sie überprüfen, ob ein Objekt in Swift vom erwarteten Typ ist.

Stellen Sie vor dem Senden einer Methode an einen Delegaten sicher, dass das Objekt vom richtigen Typ ist, damit es auf die Methode reagiert. Andernfalls stürzt die App mit einem Fehler "Nicht erkannter Selektor" ab.

Außerdem können Sie feststellen, ob ein Objekt einem Protokoll entspricht, bevor Sie versuchen, Nachrichten an dieses zu senden:

Sie können auch überprüfen, ob es einem Core Foundation-Objekttyp entspricht.

Es ist eine gute Idee, sorgfältig auszuwählen, welche Informationen vom Server dem Benutzer angezeigt werden. Es ist beispielsweise eine schlechte Idee, eine Fehlerwarnung anzuzeigen, die eine Nachricht direkt vom Server weiterleitet. Fehlermeldungen können Debugging- und sicherheitsrelevante Informationen enthalten. Eine Lösung besteht darin, dass der Server bestimmte Fehlercodes sendet, die den Client veranlassen, vordefinierte Nachrichten anzuzeigen.

Stellen Sie außerdem sicher, dass Sie Ihre URLs so codieren, dass sie nur gültige Zeichen enthalten. NSStrings stringByAddingPercentEscapesUsingEncoding funktioniert. Einige Zeichen wie kaufmännisches Und und Pluszeichen werden nicht codiert, aber die Funktion CFURLCreateStringByAddingPercentEscapes ermöglicht die Anpassung der zu codierenden Zeichen.

Benutzerdaten bereinigen

Seien Sie beim Senden von Daten an einen Server äußerst vorsichtig, wenn Benutzereingaben an Befehle übergeben werden, die von einem SQL Server oder einem Server ausgeführt werden, auf dem Code ausgeführt wird. Während die Sicherung eines Servers gegen solche Angriffe den Rahmen dieses Artikels sprengt, können wir als Entwickler von Mobilgeräten unseren Beitrag leisten, indem wir Zeichen für die vom Server verwendete Sprache entfernen, damit die Eingabe nicht für Befehlsinjektionsangriffe anfällig ist. Beispiele sind das Entfernen von Anführungszeichen, Semikolons und Schrägstrichen, wenn sie für bestimmte Benutzereingaben nicht benötigt werden.

Es wird empfohlen, die Länge der Benutzereingaben zu begrenzen. Wir können die Anzahl der in ein Textfeld eingegebenen Zeichen begrenzen, indem wir den Delegaten von UITextField festlegen und dann die Delegatenmethode shouldChangeCharactersInRange implementieren.

Für eine UITextView lautet die Delegatmethode, um dies zu implementieren:

Benutzereingaben können weiter validiert werden, sodass die Eingabe ein erwartetes Format hat. Wenn ein Benutzer beispielsweise eine E-Mail-Adresse eingeben soll, können wir nach einer gültigen Adresse suchen:

Wenn ein Benutzer ein Bild auf den Server hochlädt, können wir überprüfen, ob es sich um ein gültiges Bild handelt. Beispielsweise sind für eine JPEG-Datei die ersten zwei Bytes und die letzten zwei Bytes immer FF D8 und FF D9.

Die Liste geht weiter, aber nur Sie als Entwickler wissen, welche Ein- und Ausgabe angesichts der Entwurfsanforderungen zu erwarten ist.

URLCache

Die Daten, die Sie über das Netzwerk senden, können möglicherweise im Speicher und im Gerätespeicher zwischengespeichert werden. Sie können große Anstrengungen unternehmen, um Ihre Netzwerkkommunikation zu schützen, wie wir es getan haben, nur um herauszufinden, dass die Kommunikation gespeichert wird.

Verschiedene Versionen von iOS haben sich in Bezug auf die Cache-Einstellungen unerwartet verhalten, und einige der Regeln für das, was in iOS zwischengespeichert wird, ändern sich ständig gegenüber den Versionen. Während das Caching die Netzwerkleistung verbessert, indem es die Anzahl der Anforderungen verringert, kann es eine gute Idee sein, es für alle Daten zu deaktivieren, die Sie für hochsensibel halten. Sie können den freigegebenen Cache jederzeit entfernen (z. B. beim Start der App), indem Sie Folgendes aufrufen:

Verwenden Sie Folgendes, um das Caching auf globaler Ebene zu deaktivieren:

Wenn Sie URLSession verwenden, können Sie den Cache für die Sitzung folgendermaßen deaktivieren:

Wenn Sie ein NSURLConnection-Objekt mit einem Delegaten verwenden, können Sie den Cache pro Verbindung mit dieser Delegatenmethode deaktivieren:

Verwenden Sie zum Erstellen einer URL-Anforderung, die den Cache nicht überprüft, Folgendes:

Verschiedene Versionen von iOS 8 hatten einige Fehler, bei denen einige dieser Methoden alleine nichts bewirken würden. Das bedeutet, dass es eine gute Idee ist, den gesamten oben genannten Code für vertrauliche Verbindungen zu implementieren, wenn Sie das Zwischenspeichern von Netzwerkanforderungen zuverlässig verhindern müssen.

Die Zukunft

Es ist wichtig, die Grenzen von HTTPS zum Schutz der Netzwerkkommunikation zu kennen.

In den meisten Fällen stoppt HTTPS auf dem Server. Beispielsweise ann meine Verbindung zum Server eines Unternehmens über HTTPS erfolgen, aber sobald dieser Datenverkehr auf den Server trifft, ist er unverschlüsselt. Dies bedeutet, dass das Unternehmen die gesendeten Informationen sehen kann (in den meisten Fällen muss es), und es bedeutet auch, dass das Unternehmen diese Informationen dann unverschlüsselt weitergeben oder weitergeben kann.

Ich kann diesen Artikel nicht beenden, ohne ein weiteres Konzept zu behandeln, das ein aktueller Trend ist - die sogenannte "End-to-End-Verschlüsselung". Ein gutes Beispiel ist eine verschlüsselte Chat-App, bei der zwei mobile Geräte über einen Server miteinander kommunizieren. Die beiden Geräte erstellen öffentliche und private Schlüssel - sie tauschen öffentliche Schlüssel aus, während ihre privaten Schlüssel das Gerät niemals verlassen. Die Daten werden weiterhin über HTTPS über den Server gesendet, aber zuerst mit dem öffentlichen Schlüssel des anderen Teilnehmers so verschlüsselt, dass nur die Geräte, die die privaten Schlüssel besitzen, die Nachrichten des anderen entschlüsseln können.

Stellen Sie sich als Analogie zum besseren Verständnis der End-to-End-Verschlüsselung vor, ich möchte, dass mir jemand sicher eine Nachricht sendet, die nur ich lesen kann. Also stelle ich ihnen eine Box mit einem offenen Vorhängeschloss (dem öffentlichen Schlüssel) zur Verfügung, während ich den Vorhängeschlossschlüssel (den privaten Schlüssel) behalte. Der Benutzer schreibt eine Nachricht, legt sie in die Box, sperrt das Vorhängeschloss und sendet sie an mich zurück. Nur ich kann lesen, was die Nachricht ist, weil ich der einzige bin, der den Schlüssel zum Entsperren des Vorhängeschlosses hat.

Bei der End-to-End-Verschlüsselung stellt der Server einen Dienst für die Kommunikation bereit, kann jedoch den Inhalt der Kommunikation nicht lesen. Sie versenden die gesperrte Box, haben jedoch nicht den Schlüssel zum Öffnen. Die Implementierungsdetails gehen zwar über den Rahmen dieses Artikels hinaus, es ist jedoch ein leistungsstarkes Konzept, wenn Sie eine sichere Kommunikation zwischen Benutzern Ihrer App ermöglichen möchten.

Wenn Sie mehr über diesen Ansatz erfahren möchten, ist das GitHub-Repo für Open Whisper System, ein Open-Source-Projekt, ein Ausgangspunkt.

Abschluss

Fast alle mobilen Apps kommunizieren heute über ein Netzwerk, und Sicherheit ist ein kritisch wichtiger, aber häufig vernachlässigter Aspekt bei der Entwicklung mobiler Apps.

In diesem Artikel haben wir einige bewährte Sicherheitsmethoden behandelt, darunter einfaches HTTPS, Anwendungshärtung der Netzwerkkommunikation, Datenbereinigung und End-to-End-Verschlüsselung. Diese Best Practices sollten als Grundlage für die Sicherheit beim Codieren Ihrer mobilen App dienen.

Und während Sie hier sind, sehen Sie sich einige unserer anderen beliebten Tutorials und Kurse für iOS-Apps an!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.