Sichern der Kommunikation auf iOS

Mobile Sicherheit ist ein heißes Thema geworden. Für jede App, die remote kommuniziert, ist es wichtig, die Sicherheit der Benutzerinformationen zu berücksichtigen, die über ein Netzwerk gesendet werden. In diesem Beitrag erfahren Sie, welche bewährten Methoden zum Schutz der Kommunikation Ihrer iOS-App in Swift verwendet werden. 

Verwenden Sie HTTPS

Berücksichtigen Sie bei der Entwicklung Ihrer App, die Netzwerkanfragen auf die wesentlichen Anforderungen zu beschränken. Stellen Sie für diese Anforderungen sicher, dass sie über HTTPS und nicht über HTTP gesendet werden. Dies hilft, die Daten Ihres Benutzers vor "Man in the middle" -Angriffen zu schützen, bei denen ein anderer Computer im Netzwerk als Relay für Ihre Verbindung fungiert, aber zuhört oder ändert die übergebenen Daten. Der Trend in den letzten Jahren ist, alle Verbindungen über HTTPS herzustellen. Glücklicherweise erzwingen neuere Versionen von Xcode dies bereits.

Um eine einfache HTTPS-Anfrage unter iOS zu erstellen, müssen Sie nur das Anhängen "s" zum "http"Abschnitt der URL. 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 beliebte Bibliotheken von Drittanbietern wie AFNetworking.

App Transport-Sicherheit

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

ATS ist ab iOS 9 und OS X El Capitan verfügbar. Für aktuelle Apps im Store ist ATS nicht plötzlich erforderlich. Für Apps, die mit neueren Xcode-Versionen und deren SDKs erstellt wurden, ist dies jedoch standardmäßig aktiviert. Zu den von ATS erzwungenen Best Practices gehören die Verwendung von TLS Version 1.2 oder höher, die Vorwärtsgeheimnis durch ECDHE-Schlüsselaustausch, die AES-128-Verschlüsselung und die Verwendung von mindestens SHA-2-Zertifikaten.

Beachten Sie, dass ATS zwar automatisch aktiviert wird, dies bedeutet jedoch nicht zwangsläufig, dass ATS in Ihrer App erzwungen wird. ATS arbeitet an den Grundlagenklassen wie URLSession und NSURLConnection und Stream-basierte CFNetwork-Schnittstellen. ATS wird nicht für untergeordnete Netzwerkschnittstellen wie Raw-Sockets, CFNetwork-Sockets oder andere Bibliotheken von Drittanbietern erzwungen, die diese untergeordneten Aufrufe verwenden würden. Wenn Sie ein Netzwerk auf niedriger Ebene verwenden, müssen Sie daher die bewährten Methoden von ATS manuell implementieren.

ATS-Ausnahmen

Da ATS die Verwendung von HTTPS und anderen sicheren Protokollen erzwingt, werden Sie sich vielleicht fragen, ob Sie weiterhin Netzwerkverbindungen herstellen können, die HTTPS nicht unterstützen, z. B. beim Herunterladen von Bildern aus einem CDN-Cache. Sie können die ATS-Einstellungen für bestimmte Domänen in der Plist-Datei Ihres Projekts steuern. In Xcode finden Sie Ihr info.plist Klicken Sie mit der rechten Maustaste darauf und wählen Sie Öffnen Sie 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. 

NSAppTransportSecurity  NSExceptionDomains  yourdomain.com  NSIncludesSubdomains  NSThirdPartyExceptionRequiresForwardSecrecy    

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

  • NSAllowsArbitraryLoads: Deaktiviert ATS. Verwenden Sie das nicht! In zukünftigen Xcode-Versionen wird dieser Schlüssel entfernt.
  • 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 Ihr Medium bereits auf andere Weise verschlüsselt ist. (Verfügbar für iOS 10 und MacOS 10.12.)
  • NSAllowsArbitraryLoadsInWebContent: Kann verwendet werden, um die ATS-Einschränkungen von Webansichtobjekten in Ihrer App zu deaktivieren. Denken Sie zuerst nach, bevor Sie diese Option deaktivieren, da Benutzer beliebige, unsichere Inhalte in Ihre App laden können. (Verfügbar für iOS 10 und MacOS 10.12.)
  • NSAllowsLocalNetworking: Damit können lokale Netzwerkressourcen ohne ATS-Einschränkungen geladen werden. (Verfügbar für iOS 10 und MacOS 10.12.)

Das NSExceptionDomains Mit dem 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: Erlaubt der spezifischen Domäne, Nicht-HTTPS-Verbindungen zu verwenden.
  • NSIncludesSubdomains: Gibt an, ob die aktuellen Regeln an Unterdomänen weitergegeben werden.
  • NSExceptionMinimumTLSVersion: Wird verwendet, um ältere, weniger sichere TLS-Versionen anzugeben, die zulässig sind.

Perfekte Vorwärtsgeheimnis

Während verschlüsselter Datenverkehr nicht lesbar ist, kann er dennoch gespeichert werden. Wenn der private Schlüssel, mit dem dieser Datenverkehr verschlüsselt wird, in Zukunft gefährdet ist, kann der Schlüssel zum Lesen des zuvor gespeicherten Datenverkehrs verwendet werden. 

Um diese Art von Kompromittierung zu verhindern, generiert Perfect Forward Secrecy (PFS) einen Sitzungsschlüsseldas ist für jede Kommunikationssitzung einzigartig. Wenn der Schlüssel für eine bestimmte Sitzung gefährdet ist, werden keine Daten aus anderen Sitzungen beeinträchtigt. ATS implementiert standardmäßig PFS, und Sie können diese Funktion mithilfe des Plist-Schlüssels steuern NSExceptionRequiresForwardSecrecy. Wenn Sie diese Option deaktivieren, werden TLS-Chiffren zugelassen, die kein perfektes Vorwärtsgeheimnis unterstützen.

Zertifikattransparenz

Zertifikattransparenz ist ein bevorstehender Standard, mit dem die während des Aufbaus einer HTTPS-Verbindung vorgelegten Zertifikate geprüft oder überprüft werden können. 

Wenn Ihr Host ein HTTPS-Zertifikat einrichtet, wird es von einer so genannten Zertifizierungsstelle (Certificate Authority, CA) ausgestellt. Zertifikats-Transparenz zielt darauf ab, in Echtzeit zu überwachen, ob ein Zertifikat böswillig oder von einer angegriffenen Zertifizierungsstelle ausgestellt wurde. 

Wenn ein Zertifikat ausgestellt wird, muss die Zertifizierungsstelle das Zertifikat an eine Reihe von Protokollen für das Anhängen von Zertifikaten übergeben, die später vom Client überprüft und vom Inhaber der Domäne geprü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 NSRequiresZertifikatTransparenz. Durch Aktivieren dieser Option wird die Transparenz von Zertifikaten erzwungen. Dies ist unter iOS 10 und MacOS 10.12 und höher verfügbar.

Zertifikat und Public Key Pinning

Wenn Sie ein Zertifikat für die 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 zwischengeschalteten Behörde verwendete Zertifikat kann wiederum von einer anderen zwischengeschalteten Behörde usw. signiert werden, sofern das letzte Zertifikat von einer vertrauenswürdigen Stammzertifizierungsstelle unterzeichnet wird. 

Wenn eine HTTPS-Verbindung hergestellt wird, werden diese Zertifikate dem Client präsentiert. Diese Vertrauenskette wird ausgewertet, um sicherzustellen, dass die Zertifikate von einer Zertifizierungsstelle, die bereits von iOS als vertrauenswürdig eingestuft wurde, ordnungsgemäß signiert sind. (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. Obwohl dies ein gutes System ist, ist es nicht narrensicher. Es gibt verschiedene Schwächen, durch die iOS einem Angreifer-Zertifikat anstelle eines rechtmäßig signierten Zertifikats vertrauen kann. 

Beispielsweise können Abhörproxys ein Zwischenzertifikat besitzen, das vertrauenswürdig ist. Ein Reverse Engineer kann iOS manuell anweisen, das eigene Zertifikat zu akzeptieren. Darüber hinaus wurde das Gerät möglicherweise von einer Unternehmensrichtlinie so eingerichtet, dass sie ihr 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. Das Festlegen von Zertifikaten verhindert jedoch, dass in all diesen Szenarien Verbindungen hergestellt werden.

Das Festlegen von Zertifikaten wird durch die Überprüfung des Serverzertifikats anhand einer Kopie des erwarteten Zertifikats erreicht.

Um ein Pinning zu implementieren, muss der folgende Delegierte implementiert werden. Zum URLSession, benutze folgendes:

optionale func urlSession (_ session: URLSession, didReceive-Herausforderung: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void)

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

optionale Funkverbindung (_ Verbindung: NSURLConnection, didReceive Challenge: URLAuthenticationChallenge)

Beide Methoden ermöglichen es Ihnen, eine SecTrust Objekt von challenge.protectionSpace.serverTrust. Da wir die Authentifizierungsdelegaten überschreiben, müssen wir jetzt explizit die Funktion aufrufen, die die gerade besprochenen Standardprüfungen der Zertifikatskette durchführt. Tun Sie dies, indem Sie die SecTrustEvaluate Funktion. Dann können wir das Zertifikat des Servers mit einem erwarteten vergleichen.

Hier ist eine Beispielimplementierung.

import Foundation importieren Sicherheitsklasse URLSessionPinningDelegate: NSObject, URLSessionDelegate func urlSession (_ session: URLSession, didReceive-Anforderung: URLAuthentChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> let serverTrust = challenge.protectionSpace.serverTrust if (challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust) // Richten Sie die Richtlinie so ein, dass die Domäne validiert wird. Lassen Sie die Richtlinie als Richtlinie gelten. init (object: policy) SecTrustSetPolicies (serverTrust, Policies) Lassen Sie certificateCount: CFIndex = SecTrustGetCertificateCount (serverTrust), wenn certificateCount> 0 wenn let certificate = SecTrustGetCertificateAtIndex (serverTrust, 0) let serverCertificateDataData über Array, das abgelaufen sein kann + bevorstehendes Zertifikat lassen certFileames: [S tring] = ["CertificateRenewed", "Certificate"] für filenameString: Zeichenfolge in certFilenames let filePath = Bundle.main.path (fürResource: DateinameString, ofType: "cer") wenn let file = filePath wenn localCertData = NSData ( contentsOfFile: file) // Setzen Sie das Anker-Zertifikat auf Ihrem eigenen Server, wenn localCert: SecCertificate = SecCertificateCreateWithData (nil, localCertData) let certArray = [localCert] als CFArray SecTrustSetAnchorCertificates (serverTrust, certArray) // // das Zertifikat durch Überprüfen bestätigt Signatur plus die Signaturen der Zertifikate in ihrer Zertifikatkette, bis zum Ankerzertifikat var result = SecTrustResultType.invalid SecTrustEvaluate (serverTrust, & result); let isValid: Bool = (result == SecTrustResultType.unspecified || result == SecTrustResultType.proceed) if (isValid) // Hostzertifikat gegen gepinntes Zertifikat prüfen. if serverCertificateData.isEqual (an: localCertData as Data) success = true completionHandler (.useCredential, URLCredential (trust: serverTrust)) break // hat ein erfolgreiches Zertifikat gefunden, muss nicht mit der Schleife fortfahren // beendet, wenn serverCertificateData.isEqual (an: localCertData als Daten) // Ende, wenn (isValid) // Ende, wenn localCertData = NSData (contentsOfFile: Datei) Ende ist, wenn Datei = Dateipfad angegeben werden soll // Ende für DateinameString: Zeichenfolge in certFilenames / / end if let certificate = SecTrustGetCertificateAtIndex (serverTrust, 0) // end wenn certificateCount> 0 // end if (challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust) // end wenn ServerTrust = challenge.protectionSpace.serverTrust if ( success == false) completionHandler (.cancelAuthenticationChallenge, nil)

Um diesen Code zu verwenden, legen Sie den Delegierten von fest URLSession beim Verbindungsaufbau.

if let url = NSURL (Zeichenfolge: "https://yourdomain.com") let session = URLSession (Konfiguration: URLSessionConfiguration.ephemeral, Delegate: URLSessionPinningDelegate (), delegateQueue: nil) Lassen Sie dataTask = session.dataTask (mit: url als URL, completionHandler: (Daten, Antwort, Fehler) -> In //… ungültig) dataTask.resume ()

Stellen Sie sicher, dass das Zertifikat in Ihrem App-Paket enthalten ist. Wenn Ihr Zertifikat eine PEM-Datei ist, müssen Sie es in eine .cer-Datei im macOS-Terminal konvertieren:

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

Wenn das Zertifikat nun von einem Angreifer geändert wird, erkennt es Ihre App und lehnt die Verbindung ab.

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

Desinfektion und Validierung

Mit all den bisherigen Schutzmechanismen sollten Ihre Verbindungen gegen Angriffe von Menschen in der Mitte ziemlich sicher sein. Eine wichtige Regel für die Netzwerkkommunikation besteht jedoch darin, den Daten, die Sie empfangen, niemals blind zu vertrauen. Tatsächlich ist es eine gute Programmierpraxis Design vertraglich. DasInputs und Outputs Ihrer Methoden haben einen Vertrag, der bestimmte Schnittstellenerwartungen definiert. wenn die Schnittstelle angibt, wird ein zurückgegeben NSNumber, dann sollte es so sein. Wenn Ihr Server eine Zeichenfolge mit 24 oder weniger 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 durch Injektion und Speicherbeschädigung verringern. Allgemeine Parser wie der JSONSerialisierung Die Klasse konvertiert Text in Swift-Datentypen, wo diese Art von Tests durchgeführt werden kann.

wenn das Dictionary = Json als? [String: Any] wenn let count = Wörterbuch ["count"] als? Int //… 

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

wenn someObject NSArray ist

Bevor Sie einem Delegaten eine Methode senden, stellen Sie sicher, dass das Objekt den richtigen Typ hat, damit es auf die Methode reagiert. Andernfalls stürzt die App mit einem Fehler ab, der nicht erkannt wurde.

if someObject.responds (zu: #selector (Getter: NSNumber.intValue)

Darüber hinaus können Sie feststellen, ob ein Objekt einem Protokoll entspricht, bevor Sie versuchen, Nachrichten an das Protokoll zu senden:

if someObject.conforms (an: MyProtocol.self)

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

if CFGetTypeID (someObject)! = CFNullGetTypeID ()

Es ist eine gute Idee, sorgfältig auszuwählen, welche Informationen vom Server für den Benutzer sichtbar sind. Zum Beispiel ist es keine gute Idee, eine Fehlermeldung anzuzeigen, die eine Nachricht direkt vom Server übergibt. Fehlermeldungen können Debugging- und sicherheitsrelevante Informationen enthalten. Eine Lösung besteht darin, dass der Server bestimmte Fehlercodes sendet, die dazu führen, dass der Client vordefinierte Meldungen anzeigt.

Stellen Sie außerdem sicher, dass Sie Ihre URLs so codieren, dass sie nur gültige Zeichen enthalten. NSString's stringByAddingPercentEscapesUsingEncoding wird funktionieren. Einige Zeichen wie Ampersands und Pluszeichen werden nicht codiert, sondern die Zeichen CFURLCreateStringByAddingPercentEscapes Mit dieser Funktion können Sie anpassen, was verschlüsselt werden soll.

Benutzerdaten desinfizieren

Seien Sie beim Senden von Daten an einen Server äußerst vorsichtig, wenn eine Benutzereingabe an Befehle übergeben wird, die von einem SQL-Server oder einem Server ausgeführt werden, auf dem Code ausgeführt wird. Die Sicherung eines Servers gegen solche Angriffe liegt zwar außerhalb des Rahmens dieses Artikels. Als Entwickler von Mobilgeräten können wir jedoch dazu beitragen, dass Zeichen für die Sprache, die der Server verwendet, entfernt werden, sodass die Eingabe nicht befugt ist, Injektionsangriffe durchzuführen. Beispiele sind das Entfernen von Anführungszeichen, Semikola und Schrägstrichen, wenn sie nicht für die jeweilige Benutzereingabe benötigt werden.

var mutableString: String = string mutableString = mutableString.replacingOccurrences (of: "%", mit: "") mutableString = mutableString.replacingOccurrences (of: "\" ", mit:" ") mutableString = mutableString.replacingOccurrences: \ '", mit:" ") mutableString = mutableString.replacingOccurrences (of:" \ t ", mit:" ") mutableString = mutableString.replacingOccurrences (of:" \ n ", mit:" ")

Es empfiehlt sich, die Länge der Benutzereingaben zu begrenzen. Wir können die Anzahl der in ein Textfeld eingegebenen Zeichen begrenzen, indem Sie das Zeichen setzen UITextFieldDelegierter und dann seine Umsetzung shouldChangeCharactersInRange Methode delegieren.

func textField (_ textField: UITextField, shouldChangeCharactersIn Bereich: NSRange, ErsetzungString string: String) -> Bool let newLength: Int = textField.text! .characters.count + string.characters.count - range.length wenn newLength> maxSearchLength  false zurückgeben else return true

Für eine UITextView lautet die Delegatmethode zum Implementieren:

optionales func textField (_ textField: UITextField, shouldChangeCharactersIn Bereich: NSRange, ErsetzungString string: String) -> Bool

Die Benutzereingabe kann weiter validiert werden, so dass 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:

Klasse func validateEmail (aus emailString: String, useStrictValidation isStrict: Bool) -> Bool var filterString: String? = null, wenn isStrict filterString = "[A-Z0-9a-z.% + -] + @ [A-Za-z0-9 .-] + \\. [A-Za-z] 2,4  " else filterString =". + @. + \\. [A-Za-z] 2 [A-Za-z] * " lassen emailPredicate = NSPredicate (Format:" SELF MATCHES% @ ", filterString!) return emailPredicate.evaluate (mit: emailString)

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

Klasse func validateImageData (_ data: Data) -> Bool let totalBytes: Int = data.count wenn totalBytes < 12  return false  let bytes = [UInt8](data) let isValid: Bool = (bytes[0] == UInt8(0xff) && bytes[1] == UInt8(0xd8) && bytes[totalBytes - 2] == UInt8(0xff) && bytes[totalBytes - 1] == UInt8(0xd9)) return isValid 

Die Liste wird fortgesetzt, aber nur Sie als Entwickler wissen, was die erwarteten Ein- und Ausgaben angesichts der Designanforderungen sein sollten.

URLCache

Die über das Netzwerk gesendeten Daten können im Speicher und auf dem Gerätespeicher zwischengespeichert werden. Sie können wie gewohnt Ihre Netzwerkkommunikation schützen, nur um herauszufinden, dass die Kommunikation gespeichert wird. 

Verschiedene Versionen von iOS hatten unerwartete Verhaltensweisen, wenn es um die Cache-Einstellungen geht. Einige Regeln für das, was in iOS zwischengespeichert wird, ändern sich ständig zwischen den Versionen. Zwar hilft das Caching dabei, die Netzwerkleistung zu reduzieren, indem die Anzahl der Anforderungen reduziert wird. Das Deaktivieren der Daten für alle Daten, von denen Sie glauben, dass sie sehr sensibel sind, kann eine gute Idee sein. Sie können den gemeinsam genutzten Cache jederzeit entfernen (z. B. beim Start der App), indem Sie Folgendes aufrufen:

URLCache.shared.removeAllCachedResponses ()

Um die Zwischenspeicherung auf globaler Ebene zu deaktivieren, verwenden Sie Folgendes:

Lassen Sie den URL-Cache = URLCache (memoryCapacity: 0, diskCapacity: 0, diskPath: nil). URLCache.shared = theURLCache

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

let configuration = URLSessionConfiguration.default configuration.requestCachePolicy = .reloadIgnoringLocalCacheData configuration.urlCache = nil let Sitzung = URLSession.init (Konfiguration: Konfiguration)

Wenn Sie eine NSURLConnection Objekt mit einem Delegaten, können Sie den Cache pro Verbindung mit dieser Delegatmethode deaktivieren:

Funkverbindung (_ Verbindung: NSURLConnection, willCacheResponse cachedResponse: CachedURLResponse) -> CachedURLResponse? return nil

Um eine URL-Anforderung zu erstellen, die den Cache nicht überprüft, verwenden Sie Folgendes:

var request = NSMutableURLRequest (URL: theUrl, cachePolicy: .reloadIgnoringLocalCacheData, timeoutInterval: urlTimeoutTime)

Verschiedene Versionen von iOS 8 hatten einige Fehler, bei denen einige dieser Methoden alleine nichts ausrichten würden. Das heißt, es ist eine gute Idee, umzusetzen alles des obigen Codes für vertrauliche Verbindungen, 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 kann meine Verbindung zum Server eines Unternehmens über HTTPS hergestellt werden. Sobald dieser Datenverkehr den Server erreicht, ist er jedoch unverschlüsselt. Dies bedeutet, dass das Unternehmen die gesendeten Informationen sehen kann (in den meisten Fällen muss dies), und das Unternehmen könnte diese Informationen dann unverschlüsselt weitergeben oder weitergeben. 

Ich kann diesen Artikel nicht beenden, ohne auf ein weiteres Konzept einzugehen, das einen aktuellen Trend darstellt, der als "Ende-zu-Ende-Verschlüsselung" bezeichnet wird. 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, jedoch zuerst mit dem öffentlichen Schlüssel des anderen Teilnehmers so verschlüsselt, dass nur die Geräte, die den privaten Schlüssel enthalten, die Nachrichten des anderen Benutzers entschlüsseln können. 

Stellen Sie sich als eine Analogie vor, die Ihnen hilft, die Ende-zu-Ende-Verschlüsselung zu verstehen. Ich möchte, dass mir jemand eine sichere Nachricht sendet, die nur ich lesen kann. Also stelle ich ihnen eine Schachtel mit einem offenen Vorhängeschloss (dem öffentlichen Schlüssel) zur Verfügung, während ich den Vorhängeschlossschlüssel (den privaten Schlüssel) halte. Der Benutzer schreibt eine Nachricht, legt sie in die Box, sperrt das Vorhängeschloss und sendet es mir zurück. Nur ich kann lesen, was die Nachricht ist, weil ich der einzige bin, der den Schlüssel zum Entsperren des Vorhängeschlosses besitzt. 

Bei der Ende-zu-Ende-Verschlüsselung stellt der Server einen Dienst für die Kommunikation zur Verfügung. Der Inhalt der Kommunikation kann jedoch nicht gelesen werden. Sie senden die gesperrte Box, haben jedoch keinen Schlüssel zum Öffnen. Obwohl die Implementierungsdetails den Rahmen dieses Artikels sprengen, ist dies ein leistungsfähiges Konzept, wenn Sie eine sichere Kommunikation zwischen den Benutzern Ihrer App zulassen 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.

Fazit

Nahezu alle mobilen Apps kommunizieren heute über ein Netzwerk. Sicherheit ist ein äußerst wichtiger, aber oft vernachlässigter Aspekt der Entwicklung mobiler Apps. 

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

Wenn Sie hier sind, können Sie auch einige andere beliebte iOS App-Tutorials und -Kurse besuchen!