Sicherung von API-Schlüssel in HTTP-Anfrage

Question

Nach einem Tag der Suche nach SSL und HTTPS, bin ich völlig verwirrt, wie man etwas sehr einfaches tut. Ich habe eine kleine App, die keine Art von Benutzerauthentifizierung hat. Alle Benutzer sehen eine einfache App.

Ich versuche, Google Translate API dafür zu verwenden. Ich habe einen Übersetzungs-API-Schlüssel, aber ich weiß nicht, wie ich ihn schützen soll. Ich möchte Google Translate direkt über meine iOS-App aufrufen, und gemäß der API-Dokumentation (https://cloud.google.com/translate/docs/reference/rest) wird der apiKey als Anforderungsparameter "Schlüssel" bereitgestellt. Die API-Dokumentation sagt auch, dass Google Translate SSL unterstützt, aber offensichtlich mache ich keine SSL-Prüfungen in meiner iOS-App, um die Identität zu bestätigen. Meine Frage ist, wie kann ich einen MITM-Angriff stoppen, der meinen translate API-Schlüssel erhalten und missbrauchen kann? Ich habe versucht, Charles zu benutzen, und ich bin eindeutig in der Lage zu sehen, dass der Schlüssel durchgelassen wird.

Jede Ressource, die ich im Internet gelesen habe, sagt, dass sie SSL verwenden, und alles ist gut. Aber es gibt keine Beispiele dafür, wie SSL in iOS-Apps mit beliebten Diensten wie Google verwendet werden kann.

Irgendwelche Ideen, wie ich diese einfache GET-Anfrage machen kann und verhindern, dass mein Schlüssel gestohlen wird?

EDIT:

SSL Pinning ist ein Overkill für diese. Ich denke nicht über die Verwendung von SSL nach, aber ich habe keine Ahnung, wie das mit iOS und einer Entität wie Google funktioniert (wie unten mit @pvg diskutiert).

Answer 1

Sie versuchen, HTTPS zu verwenden, da Sie nicht möchten, dass Benutzer Ihren API-Schlüssel haben. Haben Sie Fragen dazu, wo der API-Schlüssel gespeichert werden soll, wenn Ihre App direkt eine Verbindung zu Google Übersetzer herstellt? :)

Sie müssen Ihren API-Schlüssel mit Ihrer App an Google Übersetzer verteilen. So ziemlich jeder wird es haben. Das kann oder kann kein Problem sein. Ich denke, Google API-Schlüssel werden normalerweise in Javascript an Browser-Clients gesendet, also sind sie nicht so groß wie ein Geheimnis. Die einzige Möglichkeit, sie vor Benutzern zu schützen, besteht darin, einen eigenen Server zu verwenden, der Ihre App-Abfragen unter Verwendung Ihres auf dem Server gespeicherten API-Schlüssels in Google Translate-Abfragen übersetzt.

(Vielleicht ist das offensichtlich, aber beachten Sie, dass HTTPS ein Transportprotokoll ist, es schützt Daten in Bewegung, dh wenn es über das Netzwerk gesendet wird, aber nicht Daten in Ruhe, dh wenn es in Ihrer App auf einem Handy.)

Wie Sie sicherstellen, dass niemand die Server von Google imitiert, und ob Sie Zertifikat-Pinning benötigen. Zertifikate sind Ihre Garantie, dass dies in den meisten Fällen nicht möglich ist. So ziemlich jede Standardmethode, die Sie für die Kommunikation mit einem https-Webserver, dem zugrundeliegenden Framework und/oder dem Betriebssystem wählen, überprüft das Serverzertifikat und stellt sicher, dass es keinen Identitätswechsel gibt. Dafür gibt es Zertifikate. Certificate Pinning dient dazu, die Bedrohung durch ein Rogue Trusted Root-Zertifikat zu minimieren, das auf dem Client installiert wird. Wie beispielsweise in Unternehmensnetzwerken ist es häufig der Fall, dass ein CA-Stammzertifikat als vertrauenswürdiger Stamm auf verwalteten Clients installiert wird. Ab diesem Zeitpunkt kann der Unternehmens-Proxy auch Client-SSL-Datenverkehr durch Fälschen von Serverschlüsseln und Zertifikaten anzeigen. Dies ist nur möglich, weil das Firmen-Root-Zertifikat vorinstalliert ist, für einen Angreifer ist es nicht möglich. Eine ähnliche Bedrohung liegt vor, wenn ein Angreifer es schafft, sein Zertifikat auf einem Client als vertrauenswürdiges Root zu installieren, aber das ist nicht mehr sehr häufig. Abhängig von Ihrem Bedrohungsmodell möchten Sie vielleicht Schutz dagegen, aber in den meisten Fällen genügt die Verwendung von Standard-Webclients mit einer https-API, um den Server zu validieren. Wenn Sie etwas von https://google.com herunterladen, kommt das tatsächlich von Google .com.