Frage:
Kann ein Benutzer seine Sitzungsinformationen nicht ändern, um sich als andere auszugeben?
mzcoxfde
2016-10-19 19:38:52 UTC
view on stackexchange narkive permalink

Kann ein Angreifer nicht einfach seine Sitzungsinformationen (oder Cookies, weil diese lokal gespeichert sind) ändern und dann den Server täuschen, dass er der legitime Benutzer ist?

Sagen Sie beispielsweise, wenn eine Website die Datenbank verwendet Als Kennung meldet sich der Angreifer bei seinem Konto an, um sein Cookie zu erhalten. Ändern Sie dann einfach seine ID, um sich als ein anderer legitimer Benutzer auszugeben.

Können Sie genauer erklären, was Ihr Zweck und der Kontext Ihres Problems ist?Andernfalls könnte die Antwort, die Sie gewinnen, so kurz sein wie Ihre Frage: "Ja natürlich!"
Ja, ja, sie können.
[Ja, ja, das können sie.] (Https://en.wikipedia.org/wiki/Firesheep)
Wie erhalten Sie die Datenbank-ID eines anderen legitimen Benutzers?
@immibis Nicht ganz, dass er danach gefragt hat, aber sie sind normalerweise eine automatisch inkrementelle Ganzzahl.Das heißt, sie sind sequentiell und in den allermeisten Fällen hat der Hauptverwaltungsbenutzer die ID 1. Sie werden auch in URLs verwendet, um die Profilseite eines Benutzers zu öffnen und so weiter.Kurz gesagt, die Benutzer-ID ist keine geheime Information.
Diese Frage scheint Sitzungs-IDs mit "Datenbank-ID" zu verwechseln?Oder ist das nur eine unglückliche Verwendung des Wortes "Datenbank"?@ChristianF Beziehen Sie sich auf Sitzungs-IDs oder diese "Datenbank-ID"?Sitzungs-IDs (von denen ich dachte, dass sie diese Frage betreffen) sollten keine "automatisch inkrementelle Ganzzahl" sein.
@w3d Ich beziehe mich auf den Primärschlüssel der Datenbank, da ich die Frage von immibis als solche wahrgenommen habe.Aber ja, die Frage bietet sich an, um die DB- und Sitzungs-IDs zu verwirren.
Wenn Sie die Identität einer Person stehlen, können Sie sich per Definition als solche ausgeben, unabhängig vom Kontext.Es gibt jedoch viele Möglichkeiten, um einen solchen Diebstahl zu verhindern.
Sechs antworten:
Topher Brink
2016-10-19 20:49:34 UTC
view on stackexchange narkive permalink

Ja, wenn Sie den Sitzungsschlüssel eines anderen Benutzers erraten können, können Sie dieser werden. Aus diesem Grund benötigen Sie einen unvorhersehbaren Sitzungsschlüssel, der widerrufen werden kann.

Es gab Fälle, in denen Best Practices nicht befolgt wurden. Beispielsweise hat Moonpig eine API erstellt, die einen Sitzungsschlüssel verwendet, bei dem es sich um die Benutzer-ID handelt, die bei der Kontoerstellung als fortlaufende Nummer festgelegt wird. Dies bedeutete, dass Sie jeder Benutzer sein konnten. Wenn dieser Benutzer Sie aufhalten wollte, konnte er dies nicht, da dies der Schlüssel für alle Sitzungen ist, an denen er beteiligt ist, und kann nicht geändert werden, da es sich um die eindeutige ID für ihn in der Moonpig-Datenbank handelt.

Dies ist ein wirklich gutes Beispiel dafür, wie man es falsch macht. Sitzungsschlüssel sollten unvorhersehbar sein und weggeworfen werden können (möglicherweise kann ein Benutzer viele Sitzungsschlüssel haben).

Wie in den Kommentaren von @Mindwin erwähnt, sollte sich der Sitzungsschlüssel in der HTTP-Nutzlast (Cookies) befinden oder Formulardaten [Best Practice ist in Cookies]) und nicht in der URL. Dies liegt daran, dass Sitzungsdaten in der URL dazu führen, dass Sie sie in die URL jedes Links einfügen müssen, und Sie daran hindern, eine Sitzung beizubehalten, wenn der Benutzer die URL verlässt und zurückkommt, die URL kopiert und an jemanden sendet, der ihm Ihre Sitzung gibt Daten und es gibt eine Begrenzung der Zeichen, die eine URL sein kann.

Sie sollten nach Möglichkeit auch HTTPS verwenden, damit ein Angreifer die HTTP-Nutzdaten nicht abhören und auf diese Weise eine Kopie des Sitzungsschlüssels erhalten kann (So ​​hat Firesheep funktioniert).

* Es gab Fälle, in denen dies ** nicht ** passiert ist, * Sie wollten wahrscheinlich schreiben * Es gab Fälle, in denen dies ** passiert ist **.
Ich konnte sehen, dass beide verwendet werden können, je nachdem, wie Sie den ersten Absatz interpretieren. Daher habe ich den Wortlaut leicht geändert, um zu verdeutlichen, was ich meinte.
_ "Dies liegt daran, dass die URL bei Verwendung von HTTPS nicht verschlüsselt ist" _ Nur um klar zu sein, [die URL wird bei Verwendung von HTTPS verschlüsselt] (http://stackoverflow.com/a/499594/1676444), aber alles andere, was Sie erwähnenDas Teilen des Links ist wahr.
ahh, danke @Turnerj, Ich hatte vergessen, wo sich die Dinge im Stapel befanden.
[Tom Scott hat eine wirklich gute Analyse des Moonpig-Problems] (https://youtu.be/CgJudU_jlZ8).
Vini7
2016-10-19 20:42:34 UTC
view on stackexchange narkive permalink

Ja. Dies ist möglich.

Sitzungsinformationen werden auf der Serverseite (mit Ausnahme des Sitzungstokens) gespeichert, während Cookies auf der anderen Seite auf der Clientseite (Browser) gespeichert werden. Daher kann der Angreifer das Sitzungstoken ändern, um eine Sitzung zu entführen.

Der Angriff wird allgemein als Sitzungsentführung durch Cookie-Manipulation bezeichnet. Der Angreifer muss jedoch ein gültiges Sitzungstoken verwenden, das leicht gefunden werden kann, wenn eine Site schlecht konfiguriert ist. Eine schlecht konfigurierte Site speichert möglicherweise ein Token in der URL oder generiert kein zufälliges Token usw.

Hier sind vier Hauptmethoden zum Entführen einer Sitzung:

  • Sitzungsfixierung - Wenn die Sitzungs-ID von der URL akzeptiert wird.
  • Sitzungs-Sidejacking - Wenn der Angreifer das Sitzungscookie durch Paket-Sniffing stehlen kann
  • Cross-Site-Scripting - Wenn der Angreifer den Computer des Benutzers dazu bringt, einen Code auszuführen, der als vertrauenswürdig behandelt wird, weil er zum Server zu gehören scheint, sodass der Angreifer eine Kopie des Cookies erhalten oder andere Vorgänge ausführen kann.
  • Malware - Kann einen Browser entführen, um seine Cookie-Dateien ohne Wissen eines Benutzers zu stehlen.

Die beste zu schützende Vorgehensweise besteht darin, das Sitzungstoken in einem zu speichern Plätzchen. Wenn das Sitzungstoken jedoch nicht den strengen Kriterien wie Zufälligkeit, Eindeutigkeit, Widerstand gegen statistische und kryptografische Analysen entspricht, kann ein Angreifer die Sitzung möglicherweise manipulieren.

Wie wäre es mit [CSRF] (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_ (CSRF) _Prevention_Cheat_Sheet)?Obwohl das Sitzungstoken nicht gefährdet ist, wird es dennoch für die Sitzungsentführung verwendet.
Sitzungsinformationen müssen nicht serverseitig gespeichert werden.Dies ist die übliche Implementierung, aus Sicherheitsgründen jedoch nicht obligatorisch.Stattdessen können Sie es clientseitig (z. B. in Cookies) mit einer kryptografischen Signatur speichern.
Anders
2016-10-20 01:08:29 UTC
view on stackexchange narkive permalink

Hier scheint es einige Verwechslungen zwischen Cookeis und Sitzungsinformationen zu geben. Beginnen wir also damit, dies zu klären:

  • Cookies werden auf dem Client gespeichert. Der Benutzer kann sie daher ändern, wenn er möchte.

  • Sitzungsinformationen werden auf dem Server gespeichert. Das bedeutet, dass der Benutzer es nicht ändern kann.

"Dem Client niemals vertrauen" ist eine alte Sicherheitsregel. Das bedeutet, dass Sie den Informationen in den Cookies niemals vertrauen können. Nur weil das Benutzernamen-Cookie den Wert "Alice" hat, bedeutet dies nicht, dass "Mallory" nicht derjenige war, der sich angemeldet hat.

Aus diesem Grund Wichtige Informationen werden in der Regel nicht in Cookies auf dem Client gespeichert, sondern in der Sitzung auf dem Server. Anschließend verwenden Sie ein Cookie mit einer Sitzungs-ID, um die beiden zu verbinden. Die Sitzungs-ID ist eine lange Zufallszahl. Wenn die Alice-Sitzungs-ID 20349023490324 lautet, werden auf dem Server alle Sitzungsinformationen (z. B. ihr Benutzername) unter dieser Nummer abgelegt.

Der Benutzer kann die Sitzungs-ID ändern, dies ist jedoch der Fall Bei so vielen möglichen Sitzungs-IDs ist es äußerst unwahrscheinlich, dass sie eine ID errät, die tatsächlich mit einem Benutzer verbunden ist.

In einigen Fällen möchten Sie möglicherweise trotzdem Daten in Cookies speichern. Um zu verhindern, dass der Benutzer mit ihnen herumfummelt, können Sie ihn mit einem Schlüssel signieren, den Sie nur auf dem Server haben. Da der Benutzer nicht über den Schlüssel verfügt, kann der Server Änderungen an den Cookies erkennen, da die Signatur nicht mehr übereinstimmt.

… Was darauf hindeutet, dass der Schutz vor dem Erraten von Brute-Force-Sitzungen genauso wichtig ist wie der Schutz vor dem Erraten von Brute-Force-Passwörtern.Interessant, weil ich nicht glaube, dass es so ernst genommen wird.Zum Beispiel sehe ich oft Fragen zum Sperren von Hosts nach X fehlgeschlagenen Anmeldeversuchen, aber selten, wenn überhaupt, nach X ungültigen Sitzungstoken.
@spectras Dies hängt davon ab, wie viel Entropie in Ihrer Sitzungs-ID enthalten ist.Wenn es lang und zufällig ist, kann die Sonne, die schließlich explodiert, Brute-Force-Schutz genug sein.Auf der anderen Seite, wenn es kurz oder nicht so zufällig ist ...
kaidentity
2016-10-19 20:41:33 UTC
view on stackexchange narkive permalink

Sitzungs-IDs müssen in dem Sinne kryptografisch sicher sein, dass Sie sie nicht einfach erraten können. Normalerweise handelt es sich nur um eine zufällig aussehende 128-Bit-Zahl, und es besteht keinerlei offensichtliche Verbindung zu dem Benutzer, den es identifiziert. Um sich als jemand anderes auszugeben, müssen Sie die ID dieses Benutzers finden. Es gibt verschiedene Möglichkeiten, dies zu tun, aber sie unterscheiden sich darin, es "nur zu ändern", um es zu einer anderen Person zu machen.

Der Server verfügt jedoch über eine Tabelle, die den tatsächlichen Benutzerinformationen und der zu diesem Benutzer gehörenden Sitzungs-ID entspricht kann diese Informationen verwenden. Sie können jedoch niemals die Sitzungs-ID eines anderen kennen, wenn Sie sich nur die in Ihrem Browser gespeicherte ansehen.

developerwjk
2016-10-20 02:50:56 UTC
view on stackexchange narkive permalink

So viele Antworten scheinen zu sagen, dass es in Ordnung ist, wenn die Sitzungs-ID Zufälligkeit, Eindeutigkeit, Widerstand gegen statistische und kryptografische Analysen oder ähnliches beinhaltet. Dies ist nicht wirklich wahr (wie in nicht vollständig). Ein Cookie (das diese ID enthält) muss nicht erraten werden, da es von einem Angreifer buchstäblich abgefangen und wiederverwendet werden kann. Es gibt auch seltene, aber mögliche Fälle, in denen ein Proxy- oder DMZ-Pass-Through-System Cookies verwechselt (ich habe es gesehen). Aus diesem Grund möchten Sie wahrscheinlich, dass Ihre Anwendung zusätzlich zu den oben genannten Aufgaben Folgendes ausführt:

Lassen Sie das System beim Anmelden den Benutzeragenten und die IP-Adresse der Anforderung auf der Serverseite speichern Session. Überprüfen Sie alle nachfolgenden Anforderungen und stellen Sie sicher, dass die eingehenden Werte für IP und Benutzeragent mit den in der Sitzung gespeicherten Werten übereinstimmen. Wenn nicht, machen Sie die serverseitige Sitzung ungültig und leiten Sie zum Anmeldebildschirm weiter. Dies verhindert, dass der Entführer Zutritt erhält. Als akzeptabler Nebeneffekt wird der legitime Benutzer ebenfalls rausgeschmissen (nur wenn ein Entführungsversuch stattfindet), er kann sich jedoch lediglich wieder anmelden.

Obwohl ich als Benutzer ohne statische IP-Adresse schnell sauer wäre, wenn ich mich ständig neu anmelden müsste.Vor allem, wenn ich ein langes, sicheres Passwort zum Eingeben oder ein 3-Wege-Schema habe, das ich jedes Mal durchlaufen muss.Kompromisse, denke ich.
Wenn der Angreifer das Cookie des Clients abfangen kann, kann er dann nicht auch den Agenten und die IP-Adresse abfangen und fälschen?
Der Benutzeragent bietet nicht viel Sicherheit gegen aktive Angreifer. Sie fügen der Sitzungs-ID effektiv nur einen Benutzeragenten hinzu, da jeder, der die Sitzungs-ID lesen kann, wahrscheinlich auch den Benutzeragenten lesen und fälschen kann.IP ist etwas schwieriger zu fälschen, aber es kann getan werden.Der einzige wirkliche Schutz gegen diesen Angriff besteht darin, die gesamte Kommunikation mit TLS (https) zu verschlüsseln.
Das Sitzungscookie darf nur https sein, damit es von einem Angreifer nicht buchstäblich abgefangen und wiederverwendet werden kann.Das Verwechseln von Cookies sollte nur möglich sein, wenn feindliche MITM dies absichtlich tun.
Wenn Sie mit Ihrem Mobiltelefon in einem Zug auf die Website zugreifen, springen Sie von Turm zu Turm und ändern wahrscheinlich häufig die IP-Adresse.IP-Pinning für Sitzungen sollte eine großartige Sache sein, sobald IPv6 IPv4 vollständig ersetzt hat.
Clients ändern IPs während derselben Sitzung, sodass es ziemlich nutzlos ist, den Überblick zu behalten.Der Benutzeragent kann leicht gefälscht werden, so dass er genauso effektiv ist wie das Ehrensystem.
"Clients ändern IPs während derselben Sitzung" Kann jemand dies beweisen?Ich denke, es ist eine urbane Legende.Ich habe zu Hause eine dynamische IP auf meinem DSL, und das ändert sich sicherlich nicht * so * häufig.Gib mir eine Pause.
IPs ändern sich im Allgemeinen möglicherweise nicht während einer Sitzung, aber es ist üblich, dass eine große Anzahl von Sitzungen, die verschiedenen Benutzern gehören und alle von derselben IP stammen (die gesamte Verwaltung meines Staates, Tausende von Menschen, sitzt hinter nur einer Handvoll öffentlicher IPs)..Wenn Sie sich in einem Unternehmen mit einem personalisierten (im Gegensatz zu einem zufälligen) Angriff befassen, besteht eine gute Chance, dass der Angreifer die öffentliche IP mit dem Opfer teilt.Wenn eine Sitzung die IPs ändert, wird möglicherweise ein Sicherheitsflag ausgelöst, aber das Gegenteil ist nicht unbedingt der Fall - Sie sind nicht sicher, nur weil die IP stabil bleibt.
Eine andere Sache - wenn eine Sitzung mit einer einzelnen IP beginnt, wird plötzlich eine zweite IP mit dieser Sitzung verbunden, aber die ursprüngliche IP sendet immer noch Anforderungen. Dann sollte dies wahrscheinlich auch ein Flag setzen.Es ist kein Beweis dafür, dass etwas faul ist, aber ich würde sagen, dass es eine gute Idee sein könnte, die Sitzung beim ersten Mal ungültig zu machen und den Benutzer möglicherweise entscheiden zu lassen, wie er vorgehen soll, nachdem er sich erneut angemeldet hat.Das sollte nicht passieren, wenn er eine Verbindung über eine durchschnittliche Internetverbindung zu Hause herstellt.
André Morais
2016-10-19 19:58:19 UTC
view on stackexchange narkive permalink

Ja, Websites, die keine Cookies mit aktiviertem Sicherheitsflag verwenden, können unter Cookie-Hijacking (im selben Netzwerk) leiden und sich daher als andere Benutzer ausgeben. Eine weitere Sicherheitsmaßnahme, die die Site verwenden kann, besteht darin, die Sitzungen der Benutzer zu verfolgen und zu überprüfen, wie viele Sitzungen gleichzeitig geöffnet sind. Hoffe diese Antwort dir :)

Ich denke, Sie haben die Frage vielleicht falsch verstanden.Es geht darum, dass ein Benutzer seine eigenen Cookies ändert, und das sichere Flag hilft nicht dagegen.
Schlägt diese Antwort nicht Abhilfemaßnahmen vor, um zu verhindern, dass ein Angreifer legitime Cookies unterbricht, um sie zu kopieren oder sich auszugeben?


ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...