2014-10-21 9 views
7

Ich entwerfe eine REST API in Laravel, um sie mit meiner ios App zu verwenden. Derzeit stehe ich an folgendem Punkt fest: Wie kann ich meine REST-API sichern, um Zugriff auf NUR meine iOS-App zu ermöglichen?Sichern der MY REST API zur ausschließlichen Verwendung mit der MY IOS APP

Ich habe über HTTP-Basic-Authentifizierung, HMAC, oAuth2 gelesen.

1) Die Standardauthentifizierung erfordert SSL, und Sie müssen bei jedem API-Aufruf den Benutzernamen: password senden.

  • Aber das hindert andere nicht daran, die API von anderen Anwendungen zu verwenden, vorausgesetzt, sie posten ihre Anmeldedaten an die Endpunkte?
  • 2) Ich verstehe die HMAC-Methode und wie der Client & Server sowohl Know eines öffentlichen & privaten Schlüssel. Der private Schlüssel wird zusammen mit der Anfrage und anderen Daten verschlüsselt. Der öffentliche Schlüssel wird in den Headern gesendet. Wenn der Server die Anforderung empfängt, erkennt er den öffentlichen Schlüssel in den Headern und ordnet ihn einem privaten Schlüssel in der Datenbank zu. Es berechnet dann den Hash neu und überprüft, ob es übereinstimmt. Also, ich habe die folgenden Fragen:

  • Wie erhält ein neu registrierter Benutzer den privaten Schlüssel in der IOS App gespeichert werden, wenn der private Schlüssel nicht über die Leitung gesendet werden soll?
  • Ist dies eher auf Anwendungen ausgerichtet, die Ihre App nutzen? Normalerweise sehe ich dies in einem API-Dashboard wie Instagram & Facebook, wo sie Ihnen eine App geheimer Schlüssel, richtig?
  • 3) oAuth2 - Für mich scheint das eher so zu sein, dass man sich mit einer anderen API in meine App einloggen kann. Zum Beispiel, Nutzern erlauben, sich mit meiner FB in meiner App einzuloggen und meiner API zu erlauben Facebook-Daten zu nutzen? Ich brauche das im Moment nicht wirklich.

    • bin ich das missverstanden?
    • Es hört sich so an, als müsste ich etwas Ähnliches wie die HMAC-Methode einbauen, indem ich meiner IOS-APP einen privaten Schlüssel gebe, den ich in meinem IOS-APP-Code hinterlasse. Wenn eine Anfrage innerhalb der ios app ausgeführt wird, gebe ich einen Hash mit dem privaten Schlüssel und anderen Daten weiter und dann, wenn die Anfrage auf dem Server eingeht, stelle ich fest, ob die Anfrage von einem Benutzer innerhalb der App kam, indem ich den Hash neu berechne. Ich habe keine Ahnung, ob das sicher ist & Ich würde annehmen, dass es nicht ist?

      Welches Wissen fehlt mir? Ich bin in dem Moment so verwirrt, dass das Schreiben dieser Frage ein großer Kampf war. Ich werde es überarbeiten, sobald die Dinge klarer werden.

    Antwort

    5

    1. Sie haben Recht, dies verhindert nicht nicht zugelassene Kunden.

    2. Dies ist nicht wirklich eine Möglichkeit, nicht zugelassene Clients zu verhindern, es geht vielmehr darum, zu verifizieren, dass eine Nachricht nicht über die Leitung manipuliert wird.

    3. Sie verstehen oAuth korrekt, es geht darum, Clients zu authentifizieren, Ihre API auf eine bestimmte Weise zu verwenden, sowie Berechtigungen einzuschränken.

    Es ist nicht wirklich möglich, Ihre API zu sperren, sodass nur ein bestimmter Client sie verwenden kann, da es keine Möglichkeit gibt zu überprüfen, wer der Client wirklich ist.Darüber hinaus kann jede Form der Authentifizierung oder Verifizierung, die auf der Client-Seite durchgeführt wird, eventuell reverse engineered sein und kann dann als ein "genehmigter" Client an den Server gesendet werden.

    So etwas könnte mit einem Token gemacht werden. Der Server sendet ein Token an den Client, der Client führt eine bekannte Operation auf dem Token aus, wie z. B. Salzen und Hashing, mit einer bekannten Salt- und Hash-Operation, und sendet dann das Token an prove zurück, dass der Client ein echter ist.

    Das Problem ist, wenn jemand Ihren Client zurückentwickelt, können sie bestimmen, was diese Operation ist, und dann ihren eigenen Client erstellen, der auf die gleiche Weise authentifiziert. Jede Form der clientseitigen Authentifizierung ist keine echte Sicherheit und kann nicht vertrauenswürdig sein.

    Eine andere Möglichkeit, das ist gebrochen, wenn jemand MiTM Ihre Anfrage kann. Die Anfrage könnte erfasst und geändert werden, bevor sie den Server erreicht, und es gibt keine Möglichkeiten, dies zu verhindern, abgesehen von der Verwendung von SSL, das mit etwas wie SSLStrip gebrochen werden kann.

    Jeder Versuch, einen nicht zugelassenen Client zu verhindern, ist im Grunde security through obscurity, da es keine nachweislich sichere Möglichkeit gibt, das zu tun, was Sie fragen.

    Der beste Weg, um Ihre API zu schützen, besteht nicht darin, zu beschränken, auf welche Clients zugegriffen werden darf, sondern indem sie bereits abgesichert wird. Zu den Best Practices gehört das Erzwingen von SSL, das Senden des Passworts nur einmal und die Verwendung von Token für die Authentifizierung ab diesem Zeitpunkt usw.

    +1

    Vielen Dank. Es scheint, als könnte ich SSL + Methode 2 verwenden, um MITM zu verhindern. Gibt es jedoch eine sichere Möglichkeit, den privaten Schlüssel einmal nach der Registrierung vom Server zum Client zu übertragen? Dann könnte ich es auf dem IOS-Gerät speichern. Hast du auch eine Idee, wie du die Registrierung sichern kannst? Was verhindert, dass jemand tausende Post-Anfragen an/register sendet? –

    +0

    @AlexLacayo Das Problem, das Sie versuchen zu lösen, ist; Wie verschlüsseln Sie eine Verbindung zwischen zwei Systemen, ohne dass ein Eindringling in die Konversation hineinhören und auch beitreten kann? Die Antwort ist [Public-Key-Verschlüsselung] (https://en.wikipedia.org/wiki/Public-key_cryptography). Eine SSL-Verbindung zwischen dem Client und dem Server verwendet diese Art der Verschlüsselung. Leider ist es immer noch anfällig für einen MITM-Angriff, auch auf Client-Seite entzifferbar. Sie können einen privaten Schlüssel in Ihren Client hart einprogrammieren, aber das kann auch reverse engineered sein. – Adam