Ich habe ein sicherheitsrelevantes Problem für meine iOS-Anwendung. Ich verwende HTTPS für alle meine Netzwerkanrufe, und das verwendete öffentliche Zertifikat stammt von der vertrauenswürdigen Autorität, die in der Anwendung gebündelt ist, um Main im mittleren Angriff zu verhindern (Ref: Man in the middle attack - Wiki). Ich mache SSL Pinning (Überprüfung des Zertifikats vom Server in/vor jedem Netzwerkanruf) in Android funktioniert es einwandfrei, in iOS gibt es jedoch einen TLS Session Cache, der die Zertifikatsgültigkeit nach dem ersten Netzwerkanruf zwischenspeichert.iOS Netzwerkproblem. TLS-Sitzungs-Cache-Lücke
Für den ersten Netzwerkanruf funktioniert der Zertifikatvalidierungsteil, für den zweiten Aufruf wird der Cache vom Betriebssystem verwendet und ich kann das Zertifikat nicht überprüfen. Mein QA-Team kann leicht angreifen und alle Daten vom Netzwerkanruf für den zweiten und die folgenden Netzwerkanrufe erhalten. Hier ist die Referenz für TLS Session Cache iOS documentation. Scheint, als gäbe es keine Möglichkeit, den Cache programmgesteuert ref: AdvancedURLConnections.
Ändern Abfrageparameter hilft nicht, ich habe das schon versucht. Bitte bieten Sie eine iOS-spezifische Lösung an. Ich kann meine Daten aus geschäftlichen Gründen nicht verschlüsseln.
BEARBEITEN: Ich verwende unten erwähnte Methode, um mein Zertifikat zu überprüfen. Beim ersten Netzwerkaufruf wird diese Methode vom OS aufgerufen, bei aufeinanderfolgenden Aufrufen wird diese Methode nicht aufgerufen.
willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge
Mein QA-Team macht einfach MiTM Angriff für jeden Netzanruf, versuchen sie ihr Zertifikat zu verwenden und wenn für jeden Netzanruf I Zertifikat nicht überprüfen dann können sie leicht die Daten lesen. Aufgrund des Caches kann ich mein Zertifikat nicht überprüfen.
Ich sehe nicht, wie das Serverzertifikat verifyfying, bevor jeder Netzwerkaufruf etwas zur Sicherheit hinzufügt, noch wie ein TLS-Sitzungscache Sie entweder das Zertifikat überprüfen kann * oder * Sicherheit gefährden. Ich würde gerne Details darüber sehen, wie dein QA-Team ihren MITM-Angriff durchgeführt hat. Vielleicht hat @Bruno etwas zu diesen Themen hinzuzufügen? – EJP
@Husyn - Wie EJP möchte ich etwas mehr über den Angriff auf den Cache erfahren, der zu MitM führt. Ist das der [Triple Handshake Attack] (http://secure-resception.com/), oder ein Spin drauf? – jww