Die Weitergabe von Benutzername und Passwort im HTTP-GET-Abfrage-Parameter

Baue ich eine RESTful-API für meine Anwendung und ich möchte es so sauber und transparent wie möglich.

Brauche ich zum erstellen einer Authentifizierung, endpoint-und es macht am meisten Sinn für mich, es zu bauen, so dass die Benutzer authentifizieren können, in folgender Weise:

GET https://example.com/
    auth?identity=<username_or_email>&password=<password>

Als ich sagte, die übergabe der Benutzer-auth-Daten über HTTP-GET-Methode im Abfrage-Parameter scheint sehr sauber zu mir.

Aber ich möchte Sie Fragen, wie sicher es tatsächlich ist. Da werden verschlüsselt über SSL/TLS, denken Sie, es ist eine gute Idee, um die übertragung von Benutzer-Anmeldeinformationen wie diese?

InformationsquelleAutor Hexdigit _ | 2016-04-24

  1. 7

    Als Display Name sagte, beide Varianten sind im Grunde nur text (auch mithilfe der base64-Codierung). So müssen Sie bei Verwendung von TLS oder einen anderen Schutz wie HMAC

    Aber auf der anderen Seite, Query-string ist weniger sicher in Bezug darauf, wie Client - /Server-arbeiten mit URLs im Allgemeinen. Lesen Sie dazu hier oder hier. Kurz, Sie sollten sich Gedanken über die folgenden

    • URLs gespeichert sind, in web-server-logs
    • URLs sind im browser gespeichert-Geschichte
    • URLs übergeben werden, in der Referrer-Header
    Er baut eine REST-API; nicht etwas, das besucht wird von einem end-user-web-browser, sondern stattdessen aufgerufen wird von einem anderen server. So gibt es keine browser-history und es gibt keinen referrer. Außerdem jemand, den Aufbau einer API sollte auch in der Lage sein, den server zu optimieren log-Einstellungen, so dass sensible Daten nicht protokolliert werden (z.B. stackoverflow.com/questions/9467405/...). Man sollte darüber nachdenken, diese Art von Dingen über Benutzernamen und Passwörter sowieso, vor allem mit den heutigen Regeln der Datenschutzgesetze.
    Der Punkt ist, dass es die Möglichkeit offen lässt, kann es in einem browser geöffnet werden mit der oben genannten Sicherheitsrisiken auf, warum lassen Sie die Tür angelehnt.
    Es ist nicht so dass eine Tür, da gibt es kein Risiko auf der API-Seite. Sie können nicht schützen Sie die Benutzer vor Aktionen, die nicht Teil Ihrer Anwendung werden und nur Schaden sich selbst. Diese Domäne ist unendlich.
    Nichts in der API sagt "rufen Sie nicht von einem browser aus", wer weiß, wie es in der Zukunft verwendet werden, ist die Tür offen gelassen. API ' s sollten nicht mit Vorsichtsmaßnahmen.

    InformationsquelleAutor Set

  2. 1

    Naja ich grundsätzlich-pass base64-string an den server.
    Mein Benutzername und Passwort in base64 umgewandelt und dann übergeben Sie im Authorization-Header 

    Authorization : "Basic --Value"

    Ich finde das die sauberste Art der übergabe von Benutzername und Kennwort an den server.

    Am anderen Ende , der server hatte ein Modul mit dem Namen passport.Passport bietet verschiedene Art von Autorisierung und Authentifizierung wie Basic,Träger,token, oder sogar Ihre eigenen benutzerdefinierten.

    Für den oben genannten Zweck verwende ich Basic-Modul.

    Die Frage ist "wie sicher es tatsächlich ist". Die Authorization header ist im Grunde nur text. Es kann nur sicher sein, wenn TLS verwendet wird.

    InformationsquelleAutor maddygoround

  3. 0

    Aus der Sicht der Sicherheit ist es egal, ob Sie Anmeldeinformationen übergeben, die als query-Parameter oder in den Authentication Header. Beide sind im Grunde nur text. Damit Sie muss TLS verwenden.

    Vom REST Standpunkt, Ihre URL sieht wie RPC: Aufruf einer Methode auth, die zwei Parameter akzeptiert identity und password. Was ist die REST-Ressource URL repräsentiert? Was passiert, wenn Sie einen zweiten GET Anfrage mit den gleichen Parametern? Was ist die Antwort?

    Vielen Dank für Ihre Antwort. Reden über den REST Sicht, Anfragen dieser Art sollten zurück authenticatio Daten wie: {"authToken": "x7kkoal1vf4uk34ikzep"}. Machen die requestst wiederholt sollte wohl erlöschen alle vorherigen authTokens und reagieren mit ähnlichen JSON-formatierte Daten.

    InformationsquelleAutor

Schreibe einen Kommentar