Senden von Passwörtern über HTTPS: GET vs POST

Question

Ich erstelle eine kopflose API, die ein Angular-Frontend ansteuert. Ich habe ein wenig Mühe, herauszufinden, wie ich mit der Benutzerauthentifizierung umgehen sollte.

Offensichtlich sollte die API über SSL laufen, aber die Frage, die kommt, ist wie ich die Anfrage senden soll, die das Passwort des Benutzers enthält: über GET oder POST. Es ist eine RESTFUL API, also was ich mache, ist das Abrufen von Informationen, was bedeutet, dass es eine GET-Anfrage erhalten sollte. Aber das Senden des Passworts über get bedeutet, dass es Teil der URI ist, richtig? Ich weiß, dass sogar eine GET-Anfrage über HTTPS verschlüsselt ist, aber ist das immer noch der richtige Weg? Oder ist dies ein Fall, um aus RESTFUL zu brechen und die Daten im Körper oder etwas zu haben (kann eine GET-Anfrage Daten im Körper haben?).

Answer 1

Wenn Sie die Anmeldeinformationen in einem Anforderungsheader übergeben, können Sie entweder eine GET- oder eine POST-Anfrage ausführen. Sie haben die Möglichkeit, den festgelegten Berechtigungsheader mit dem von Ihnen gewählten Authentifizierungsschema zu verwenden, oder Sie können benutzerdefinierte Header erstellen, die für Ihre API spezifisch sind.

Wenn Sie Headerfelder zum Übertragen von Anmeldeinformationen verwenden, müssen Sie nicht befürchten, dass die Anmeldeinformationen in das Zugriffsprotokoll geschrieben werden, da in diesem Protokoll keine Header enthalten sind. Die Verwendung von Kopffeldern entspricht ebenfalls den REST-Standards und sollte tatsächlich verwendet werden, um irgendwelche Metadaten zu übertragen, die für die Ressourcenanforderung/-antwort relevant sind. Solche Metadaten können Informationen wie: Sammlungsgröße, Paginierungsdetails oder Orte verwandter Ressourcen umfassen, sind aber nicht darauf beschränkt.

Zusammenfassend verwenden Sie immer Kopffelder als Mittel zur Authentifizierung/Autorisierung.

Answer 2

Sie könnten auch einen Datenkörper mit einer Abrufanforderung senden, aber das wird nicht von allen Bibliotheken unterstützt, denke ich.

Besser zu verwenden POST oder Header anfordern. Sehen Sie sich andere APIs an und wie sie damit umgehen.

Aber man konnte immer noch GET wie hier mit der Standardauthentifizierung: http://restcookbook.com/Basics/loggingin/

Answer 3

meist GET-Anforderungsdaten in URL binden selbst ... so ist es mehr als redable POST .. also, wenn es GET , gibt es eine Möglichkeit, um am leben GESCHICHTE LOG

mit ?user=myUsername&pass=MyPasswort genau ist wie eine GET-basiertes Formular verwenden und, während der Referer Ausgabe enthalten sein können, die Probleme in Bezug auf Protokolle und Geschichte bleiben.

Das Senden von vertraulichen Daten über GET ist gefährlich, auch wenn es sich um HTTPS handelt. Diese Daten enden möglicherweise in Protokolldateien auf dem Server und werden in den Referer-Header in Verknüpfungen zu anderen Seiten aufgenommen. Sie werden auch in der Browserhistorie gespeichert, sodass ein Angreifer versuchen kann, den ursprünglichen Inhalt des Links mit einem Angriff auf den Verlauf zu erraten und zu verifizieren.