it-swarm.com.de

Sicherheit von REST Authentifizierungsschemata

Hintergrund:

Ich entwerfe das Authentifizierungsschema für einen REST Webdienst. Dies muss nicht "wirklich" sicher sein (es ist eher ein persönliches Projekt), aber ich möchte es so sicher wie möglich machen Als Übung/Lernerfahrung möglich. Ich möchte kein SSL verwenden, da ich den Aufwand und vor allem die Kosten für die Einrichtung nicht möchte.

Diese SO Fragen waren besonders nützlich, um mich anzufangen:

Ich denke über die Verwendung einer vereinfachten Version von Amazon S3-Authentifizierung (Ich mag OAuth , aber es scheint zu kompliziert für meine Bedürfnisse). Ich füge der Anfrage ein zufällig generiertes nonce hinzu, das vom Server bereitgestellt wird, um Wiederholungsangriffe zu verhindern.

Um zur Frage zu kommen:

Sowohl S3 als auch OAuth sind darauf angewiesen, die Anforderungs-URL zusammen mit einigen ausgewählten Headern zu signieren. Keiner von beiden signiert den Anforderungshauptteil für POST oder PUT-Anforderungen. Ist dies nicht anfällig für einen Man-in-the-Middle-Angriff, bei dem die URL und die Header beibehalten werden und der Anfragetext durch die vom Angreifer gewünschten Daten ersetzt wird?

Es scheint, als könnte ich mich dagegen wehren, indem ich einen Hash des Anforderungshauptteils in die Zeichenfolge einfüge, die signiert wird. Ist das sicher?

224
dF.

Eine frühere Antwort erwähnte nur SSL im Zusammenhang mit der Datenübertragung und deckte die Authentifizierung nicht wirklich ab.

Sie fragen sich wirklich nach der sicheren Authentifizierung von REST API-Clients. Sofern Sie nicht die TLS-Clientauthentifizierung verwenden, sollte nur SSL verwendet werden. ist KEIN praktikabler Authentifizierungsmechanismus für eine REST API. SSL ohne Clientauthentifizierung authentifiziert nur den Server , was irrelevant ist für die meisten REST APIs, da Sie den Client wirklich authentifizieren möchten .

Wenn Sie keine TLS-Clientauthentifizierung verwenden, müssen Sie ein Digest-basiertes Authentifizierungsschema (wie das benutzerdefinierte Schema von Amazon Web Service) oder OAuth 1.0a oder sogar HTTP Basic-Authentifizierung) verwenden (aber nur über SSL).

Diese Schemata bestätigen, dass die Anforderung von einer erwarteten Person gesendet wurde. TLS (SSL) (ohne Client-Authentifizierung) stellt sicher, dass die über die Leitung gesendeten Daten nicht manipuliert werden. Sie sind getrennte, aber sich ergänzende Anliegen.

Für Interessierte habe ich eine SO Frage zu HTTP-Authentifizierungsschemata und wie sie funktionieren erweitert.

166
Les Hazlewood

REST bedeutet, mit den Standards des Webs zu arbeiten, und der Standard für die "sichere" Übertragung im Web ist SSL. Alles andere wird unkonventionell und erfordert zusätzlichen Bereitstellungsaufwand für Clients, für die Verschlüsselungsbibliotheken verfügbar sein müssen.

Sobald Sie sich für SSL entschieden haben, ist für die Authentifizierung im Prinzip nichts Besonderes mehr erforderlich. Sie können wieder mit Webstandards arbeiten und HTTP Basic-Authentifizierung (Benutzername und geheimes Token, die zusammen mit jeder Anforderung gesendet werden) verwenden, da dies viel einfacher ist als ein ausgeklügeltes Signaturprotokoll und im Kontext einer sicheren Verbindung immer noch effektiv ist. Sie müssen nur sicherstellen, dass das Passwort niemals über Klartext geht. Wenn das Kennwort jemals über eine Nur-Text-Verbindung empfangen wird, können Sie das Kennwort sogar deaktivieren und dem Entwickler eine E-Mail senden. Sie sollten auch sicherstellen, dass die Anmeldeinformationen nach Erhalt nicht an irgendeiner Stelle protokolliert werden, so wie Sie kein reguläres Kennwort protokollieren würden.

HTTP Digest ist ein sicherer Ansatz, da es verhindert, dass das geheime Token weitergegeben wird. Stattdessen handelt es sich um einen Hash, den der Server am anderen Ende überprüfen kann. Wenn Sie die oben genannten Vorsichtsmaßnahmen getroffen haben, kann dies für weniger empfindliche Anwendungen zu viel des Guten sein. Immerhin wird das Passwort des Benutzers bereits beim Anmelden im Klartext übertragen (es sei denn, Sie verwenden eine ausgefallene JavaScript-Verschlüsselung im Browser), und ebenso die Cookies bei jeder Anforderung.

Beachten Sie, dass es bei APIs für den Client besser ist, Token (zufällig generierte Zeichenfolgen) anstelle des Kennworts zu übergeben, mit dem sich der Entwickler auf der Website anmeldet. Daher sollte der Entwickler in der Lage sein, sich bei Ihrer Site anzumelden und neue Token zu generieren, die für die API-Überprüfung verwendet werden können.

Der Hauptgrund für die Verwendung eines Tokens besteht darin, dass es bei einer Beschädigung ersetzt werden kann. Bei einer Beschädigung des Kennworts kann sich der Eigentümer beim Konto des Entwicklers anmelden und alles tun, was er möchte. Ein weiterer Vorteil von Token ist, dass Sie mehrere Token an dieselben Entwickler ausgeben können. Vielleicht, weil sie mehrere Apps haben oder weil sie Token mit unterschiedlichen Zugriffsebenen möchten.

(Aktualisiert, um die Auswirkungen der Herstellung der Verbindung nur über SSL abzudecken.)

60
mahemoff

Alternativ können Sie die bekannte Lösung für dieses Problem verwenden und SSL verwenden. Selbstsignierte Zertifikate sind kostenlos und ein persönliches Projekt, oder?

8
wowest

Wenn Sie den Hash des Körpers als einen der Parameter in der URL benötigen und diese URL über einen privaten Schlüssel signiert ist, kann ein Man-in-the-Middle-Angriff den Körper nur durch Inhalt ersetzen, der den erzeugen würde Gleicher Hash. Mindestens jetzt mit MD5-Hashwerten leicht zu machen, und wenn SHA-1 defekt ist, haben Sie das Bild.

Um den Körper vor Manipulationen zu schützen, müssten Sie eine Signatur des Körpers anfordern, die ein Man-in-the-Middle-Angriff mit geringerer Wahrscheinlichkeit verhindern kann, da er den privaten Schlüssel, der die Signatur generiert, nicht kennt .

5
ZaDDaZ

Tatsächlich ermöglicht die ursprüngliche S3-Authentifizierung does das Signieren des Inhalts, wenn auch mit einer schwachen MD5-Signatur. Sie können einfach die optionale Vorgehensweise erzwingen, einen Content-MD5-Header in die HMAC (zu signierende Zeichenfolge) aufzunehmen.

http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

Ihr neues v4-Authentifizierungsschema ist sicherer.

http://docs.aws.Amazon.com/general/latest/gr/signature-version-4.html

3
djsadinoff

Denken Sie daran, dass Ihre Vorschläge den Clients die Kommunikation mit dem Server erschweren. Sie müssen Ihre innovative Lösung verstehen und die Daten entsprechend verschlüsseln. Dieses Modell eignet sich nicht für öffentliche APIs (es sei denn, Sie sind Amazon\yahoo\google ..).

Wenn Sie jedoch den Inhalt verschlüsseln müssen, empfehle ich Ihnen, vorhandene Standards und Lösungen wie die folgenden zu prüfen:

XML-Verschlüsselung (W3C-Standard)

XML-Sicherheit

1
LiorH