it-swarm.com.de

Wie mache ich eine zustandslose (sitzungslose) und cookielose Authentifizierung?

Bob nutzt eine Webanwendung, um etwas zu erreichen. Und:

  • Sein Browser ist auf Diät, daher unterstützt er nicht Cookies.
  • Die Webanwendung ist sehr beliebt, sie beschäftigt sich zu einem bestimmten Zeitpunkt mit vielen Benutzern - sie muss skalieren gut sein. Solange das Beibehalten der Sitzung eine Beschränkung der Anzahl gleichzeitiger Verbindungen bedeutet und natürlich eine nicht zu vernachlässigende Leistungsstrafe zur Folge hat, möchten wir möglicherweise eine Sitzungsloses System :)

Einige wichtige Hinweise:

  • wir haben Transportsicherheit ( [~ # ~] https [~ # ~] und seine besten Freunde);
  • hinter den Kulissen delegiert die Webanwendung viele Vorgänge an externe Dienste, im aktuellen Namen des Benutzers (diese Systeme erkennen Bob als einen ihrer Benutzer) - dies bedeutet, dass wir müssen ihnen Bobs Anmeldeinformationen übermitteln.

Wie authentifizieren wir Bob (bei jeder Anfrage)? Was wäre ein vernünftiger Weg, so etwas umzusetzen?

  • spielen tennis mit den Anmeldeinformationen über HTML-Formular ausgeblendete Felder ... der ball enthält die Anmeldeinformationen (Benutzername & Passwort) und die zwei Schläger sind der Browser bzw. die Webanwendung. Mit anderen Worten, wir können Daten über Formularfelder anstatt über Cookies hin und her transportieren. Bei jeder Webanforderung sendet der Browser die Anmeldeinformationen. Im Falle einer einseitigen Anwendung kann dies so aussehen, als würde man Squash gegen eine Gummiwand spielen, anstatt Tennis, da das Webformular, das die Anmeldeinformationen enthält, möglicherweise die gesamte Lebensdauer der Webseite am Leben erhalten bleibt (und der Server so konfiguriert wird, dass das nicht angeboten wird Zugangsdaten zurück).
  • speichern des Benutzernamens und des Passworts im Kontext der Seite - JavaScript-Variablen usw. Einzelseite hier erforderlich, IMHO.
  • verschlüsselte tokenbasierte Authentifizierung. In diesem Fall würde die Anmeldeaktion zur Erzeugung eines verschlüsselten Sicherheitstokens (Benutzername + Passwort + etwas anderes) führen. Dieses Token wird dem Kunden zurückgesandt, und die anstehenden Anforderungen werden vom Token begleitet. Macht das Sinn? Wir haben bereits HTTPS ...
  • andere...
  • letzter Ausweg: Tun Sie dies nicht, speichern Sie die Anmeldeinformationen in der Sitzung! Die Sitzung ist gut. Mit oder ohne Cookies.

Denken Sie an irgendwelche Web-/Sicherheitsbedenken in Bezug auf eine der zuvor beschriebenen Ideen? Beispielsweise,

  • Auszeit - wir können ein Zeitstempel zusammen mit den Anmeldeinformationen (Zeitstempel = die Zeit, zu der Bob seine Anmeldeinformationen eingegeben hat) aufbewahren. Z.B. Wenn JETZT - Zeitstempel> Schwelle, lehnen wir die Anforderung möglicherweise ab.
  • Cross-Site Scripting Schutz - sollte in keiner Weise anders sein, oder?

Vielen Dank, dass Sie sich die Zeit genommen haben, dies zu lesen :)

105
turdus-merula

Ah, ich liebe diese Fragen - eine Sitzung ohne Sitzung zu führen.

Ich habe während meiner Aufenthalte bei der Beurteilung von Bewerbungen mehrere Möglichkeiten gesehen, dies zu tun. Eine der gängigen Methoden ist die von Ihnen erwähnte Tennis spielen - Senden des Benutzernamens und des Kennworts bei jeder Anforderung zur Authentifizierung des Benutzers. Dies ist meiner Meinung nach unsicher, insbesondere wenn es sich bei der Anwendung nicht um eine einzelne Seite handelt. Es ist auch nicht skalierbar, insbesondere wenn Sie Ihrer App in Zukunft zusätzlich zur Authentifizierung eine Autorisierung hinzufügen möchten (obwohl Sie wahrscheinlich auch etwas basierend auf den Anmeldungen erstellen könnten).

Ein beliebter, wenn auch nicht vollständig zustandsloser Mechanismus (vorausgesetzt, Sie haben JavaScript ausgeführt) ist das Einbetten des Sitzungscookies in JavaScript. Der Sicherheitsbeamte in mir schreit darüber, aber es könnte tatsächlich funktionieren - jede Anfrage hat ein X-Authentication-Token -Header oder so ähnlich, und Sie ordnen das einer Datenbank, einem Dateispeicher im Speicher usw. im Backend zu, um den Benutzer zu validieren. Dieses Token kann eine von Ihnen festgelegte Zeitüberschreitung aufweisen. Bei einer Zeitüberschreitung muss sich der Benutzer erneut anmelden. Es ist ziemlich skalierbar - wenn Sie es in einer Datenbank speichern, eine SQL-Anweisung ausführen und die richtigen Indizes verwenden, sollte die Ausführung auch bei mehreren gleichzeitigen Benutzern sehr wenig Zeit in Anspruch nehmen. Lasttests hier würden auf jeden Fall helfen. Wenn ich die Frage richtig lese, ist dies Ihr verschlüsselter Token-Mechanismus. Ich würde jedoch dringend empfehlen, dass Sie ein kryptografisch zufälliges Token mit beispielsweise 32 Zeichen verwenden, statt eine Kombination aus Benutzername + Passwort + was auch immer zu verwenden - dies bleibt so unvorhersehbar, aber Sie können es immer noch mit der Benutzer-ID oder etwas Ähnlichem verknüpfen.

Was auch immer Sie verwenden, stellen Sie sicher, dass es Ihnen sicher zugesandt wird. HTTPS schützt Sie drahtlos, schützt Sie jedoch nicht, wenn Sie das Sitzungstoken über die URL (oder schlimmer noch, Anmeldeinformationen über die URL) verlieren. Ich würde empfehlen, einen Header zu verwenden oder, falls dies nicht möglich ist, das Token jedes Mal über eine POST) -Anforderung zu senden (dies würde bedeuten, dass das Formularfeld im Browser des Benutzers ausgeblendet ist.) Eine POST Anfrage sollte CSRF-Abwehr verwenden, nur für den Fall, dass ich vermute, dass die Verwendung des Tokens selbst eine Art CSRF-Abwehr sein könnte.

Stellen Sie als letztes sicher, dass im Backend ein Mechanismus zum Löschen abgelaufener Token vorhanden ist. Dies war in der Vergangenheit der Fluch vieler Anwendungen - eine schnell wachsende Datenbank mit Authentifizierungstoken, die scheinbar nie verloren geht. Wenn Sie mehrere Benutzeranmeldungen unterstützen müssen, müssen Sie entweder die Anzahl begrenzen oder für jedes Token ein kürzeres Zeitlimit festlegen. Wie ich bereits sagte, könnten Lasttests die Antwort darauf sein.

Es gibt einige andere Sicherheitsbedenken, die ich mir vorstellen kann, aber die sind zu weit gefasst, um sie in dieser Phase anzugehen. Wenn Sie alle Anwendungsfälle (und Missbrauchsfälle) berücksichtigen, sollten Sie wahrscheinlich in der Lage sein, eine recht gute Implementierung von durchzuführen dieses System.

73

Über die Anmeldeoption - Ich denke, dass Sie normalerweise Sitzungen auch für Gäste unterstützen möchten.

Wenn Sie die Anmeldung erzwingen möchten, ist die Option für verschlüsselte Token möglicherweise hilfreich. Es könnte auch irgendwie gut für Gastsession sein. In einer anderen Richtung würde ich zwischen dem Anhängen des Tokens an die URL und der Tennisoption kombinieren.

Beachten Sie, dass das Senden von Anmeldeinformationen nur in der URL gefährlich sein kann. Beispielsweise können Sie das Token über den HTTP-Referer-Header oder sogar durch jemanden verlieren, der nur Ihren Datenverkehr überprüft oder Ihren Computer überwacht.

Auch wenn Sie Cookies verwenden könnten, würde ich Ihnen empfehlen, ein zufälliges Token oder einen zufälligen Verifer hinzuzufügen, um sich vor Cross Site Request Forgery (CSRF) -Angriffen zu schützen.

1
Gari BN