Session-Hijacking verhindern
Wie wollen Sie verhindern, dass mehrere clients mit den gleichen session-ID? Ich Frage das, weil ich will, um eine zusätzliche Ebene der Sicherheit, um zu verhindern, dass session-hijacking-Angriffe auf meine website. Wenn ein hacker irgendwie die zahlen aus anderen Benutzers Sitzungs-ID und Anfragen mit, dass SID, wie kann ich erkennen, dass es verschiedene clients den Austausch einer einzelnen SID, die auf dem server und dann lehnen die hijack-Versuch?
BEARBEITEN
Habe ich angenommen Gumbo Antwort, nach reiflicher überlegung, denn ich habe zu der Erkenntnis kommen, dass das, was ich Frage ist unmöglich, aufgrund der Beschränkungen des zustandslose HTTP-Protokoll. Ich vergaß, was ist vielleicht die grundlegendste, HTTP, und jetzt, dass ich denke, über diese Frage scheint ein bisschen trivial.
Lassen Sie mich aufwendige, was ich meine:
Nachdem Benutzer A anmeldet example.com er ist einige zufällige session-ID, der Einfachheit halber, lass es sein 'abc123'. Diese session-ID gespeichert ist, als ein Plätzchen auf der client-Seite und ist validiert mit einem server-side-Sitzung, um sicherzustellen, der Benutzer, der angemeldet angemeldet bleibt, wie er wechselt von einer Webseite zur anderen. Dieses cookie würde natürlich nicht vorhanden sein müssen, wenn der HTTP-wurden nicht staatenlos. Aus diesem Grund, wenn Benutzer B Stiehlt Benutzer Eine SID, und erstellt ein cookie auf seinem computer mit dem Wert 'abc123', er hätte erfolgreich gekapert Benutzer Eine Sitzung, aber es gibt einfach keine Möglichkeit für den server, um rechtmäßig zu erkennen, dass Benutzer B die Anfrage ist jede andere von der Benutzer Eine s-Anforderungen, und daher hat der server keinen Grund für eine Ablehnung einer Anfrage. Selbst, wenn wir auf die Liste der Sitzungen, die waren schon auf dem server aktiv und versuchen zu sehen, ob jemand Zugriff auf eine session, die bereits aktiv ist, wie können wir feststellen, dass es ein anderer Benutzer, der Zugriff auf die session-unehelich und nicht der gleiche Benutzer bereits angemeldet ist mit einer session-ID, sondern einfach versuchen zu machen, ein weiterer Antrag (ie, navigieren Sie zu einer anderen Webseite). Wir können es nicht. Die überprüfung der user-agent? Manipuliert werden können - aber gut, wie eine Verteidigung in der Tiefe Messen Sie trotzdem. Die IP-Adresse? Ändern kann sich aus berechtigten Gründen - aber anstatt die Prüfung nicht für die IP-Adresse an alle, ich schlage vor, die überprüfung etwas wie die ersten beiden Oktette der IP -, als auch ein Benutzer auf einen Daten-plan-Netzwerk, die ständig eine wechselnde IP für vollkommen legitime Gründe wären in der Regel nur die letzten beiden Oktette Ihrer IP ändern.
In consclusion, es ist das zustandslose HTTP, verurteilt uns, dass Sie nie in der Lage, vollständig schützen unsere Webseiten, session hijacking, aber gute Praktiken (wie Gumbo zur Verfügung gestellt hat) wird gut genug sein, um zu verhindern, dass eine gute Mehrheit von session-Angriffe. Zu schützen versuchen, die Sitzungen von der Entführung durch die Verweigerung der mehrere Anfragen von der gleichen SID ist daher einfach lächerlich, und würde den ganzen Zweck vereiteln, Sitzungen.
InformationsquelleAutor der Frage hesson | 2012-09-02
Du musst angemeldet sein, um einen Kommentar abzugeben.
Leider gibt es keinen effektiven Weg, um unverkennbar zu identifizieren, eine Anforderung, die stammt von einem Angreifer im Gegensatz zu einer echten Anfrage. Da die meisten Eigenschaften, die Gegenmaßnahmen überprüfen Sie die IP-Adresse oder user-agent-Eigenschaften sind entweder nicht zuverlässig (IP-Adresse ändern kann bei mehreren Anfragen) oder geschmiedet werden kann, leicht (e. g. User-Agent - request-header) und kann so die Ausbeute unerwünschte false-positives " (ich. e. echte Benutzer eingeschaltet, IP-Adresse) oder false negatives (ich. e. Angreifer war in der Lage, erfolgreich Schmieden-request mit gleichen User-Agent).
Deshalb ist die beste Methode, um zu verhindern, dass session-hijacking ist, um sicherzustellen, dass ein Angreifer nicht herausfinden kann, einem anderen Benutzer die session-ID. Das heißt, Sie sollten Ihre Anwendung und Ihre session-management, dass (1) ein Angreifer nicht erraten einer gültigen session-ID mit genügend Entropie, und (2) dass es keine andere Möglichkeit für einen Angreifer, um einen gültigen session-ID, durch bekannte Angriffe/vulerabilities wie sniffing das Netzwerk-Kommunikation, Cross-Site-Scripting -, Leckage durch Referer, etc.
Sagte, man soll:
HttpOnly
undSecure
Attribute zu verbieten den Zugriff über JavaScript (im Falle von XSS-Schwachstellen) und verbieten die übertragung über unsicheren Kanal (siehe session.cookie_httponly und session.cookie_secure)Außerdem sollten Sie auch neu generieren der session-ID ungültig zu machen, während die alte (siehe
session_regenerate_id
- Funktion) nach bestimmten Sitzungsstatus (e. g. Bestätigung der Authentizität nach der Anmeldung oder änderung der Berechtigung/Berechtigungen) und Sie können zusätzlich tun Sie dies regelmäßig, um die Verringerung der Zeitspanne für eine erfolgreiche session hijacking-Angriff.InformationsquelleAutor der Antwort Gumbo
Können wir so etwas tun.
Speichern session-id in der Datenbank.
Auch speichern die Ip-Adresse und den HTTP_USER_AGENT für die session-id.
Wenn jetzt eine Anfrage kommt, um die server mit dem passenden session-id, Überprüfen Sie, von dem agent und die ip ist die von deinem Skript.
Kann diese funda Arbeit durch gemeinsame Funktion oder Klasse für die Sitzung, so dass jede Anfrage überprüft wird, bevor es verarbeitet wird. Es würde kaum einige micro Sekunden. Aber, Wenn viele Benutzer Ihre Website besuchen und Sie haben eine riesige Datenbank von Sitzungen, könnte dieses kleines performance-Problem. Aber, wäre Es sicherlich sehr sicher im Vergleich o andere Methoden wie
=> Mit regenerierenden Sitzungen.
Bei der Regeneration von session-ids gibt es wieder kaum eine chance, session-hijacking-Angriffe.
angenommen, Benutzer - session-id kopiert wird, und dass der Benutzer nicht arbeitet oder aktiv für irgendwann, und keine Anfrage zum server mit der alten session-id Fragen, um zu regenerieren, neue. Dann In der Fall session-id wird entführt, die hacker verwenden, dass die session-id und machen die Anfrage an den server mit dieser id, dann server antwortet wieder mit Regenerierter session-id und so, die hacker gehen können, auf die Nutzung der Dienste. Der Benutzer wird nicht mehr in der Lage sein zu bedienen, weil er unbekannt ist, was die regeneriert id ist und was Anfrage die session-id wird übergeben werden in der Anfrage. Völlig Verschwunden.
Bitte korrigieren Sie mich, wenn ich m falsch irgendwo.
InformationsquelleAutor der Antwort kanchan
Gibt es viele standard-Verteidigung gegen session-hijacking-Angriffe. Einer von Ihnen ist zu entsprechen, wird jede Sitzung zu einem einzigen IP-Adresse.
Andere Systeme ein HMAC generiert aus:
Grunde nur die Netzwerk-Adresse der IP verwendet wird, ist im Falle dass der Nutzer hinter einem öffentlichen proxy, in dem Fall Ihre IP-Adresse kann sich ändern, mit jeder Anfrage, aber die Netzwerk-Adresse gleich bleibt.
Natürlich, wirklich sicher sein, Sie sollten wirklich erzwingen von SSL für alle Anfragen so, dass die SID kann nicht abgefangen werden würden-Angreifer in den ersten Platz. Aber nicht alle Seiten in diesem (::Husten:: - Stack Overflow ::Husten::).
InformationsquelleAutor der Antwort Lèse majesté
Meiner Ansicht können Sie speichern, session-id in der Datenbank, wenn die Benutzer-Anmeldung und prüfen alle für die gleichen, vor dem loggin. löschen Sie die gleiche session-id, die Sie in der Datenbank gespeichert, wenn Benutzer Abmelden. Sie können leicht findout session-id an jeden Benutzer oder anderes kann ich dir helfen.
InformationsquelleAutor der Antwort Sk MiRaj
Einer der einfache Implementierungen kann getan werden, indem eine Tabelle in der Datenbank , als angemeldeter Benutzer , dann auf login, update, Tabelle mit Benutzer-Namen und seinem SID , dies wird verhindern, dass andere Anmeldungen als derselbe user , der jetzt an der Zeit, sich Abmelden , führen Sie einfach eine einfache Abfrage , die löscht die protokollierten Daten in der Datenbank , dies kann auch verwendet werden, um trace-angemeldete user auf ur-website zu einer Zeit .
InformationsquelleAutor der Antwort Ratan Kumar
Natürlich, wenn Sie session-cookie im browser, das cookie in der Anfrage. Nun, wenn die Anfrage kommt, der Server überprüft die session-id in der Datenbank und den Zugriff gewähren. Um zu verhindern, dass nur die wichtigsten zu speichern-agent und ip, so dass vor dem Check-server stellt sicher, dass die Sitzungen der Zugriff auf die unique-client-und nicht die eindeutige session-id, die in Geiselhaft genommen werden können.
InformationsquelleAutor der Antwort kanchan
Ich weiß nicht über die Codierung Teil. Also ich kann sagen, u ein Algorithmus, dies zu tun. Einstellung stopft, wie SSL, oder die Einstellung der session-cookie, um secure und httpOnly nicht funktionieren, wenn ein Benutzer schnuppert die session-id von einem LAN-Netzwerk(Sofern sich Nutzer und Angreifer im gleichen LAN).
Also, was Sie tun können, ist, sobald der Benutzer meldet sich erfolgreich in der Anwendung, einzigartige token auf jeder und jede Seite der web-Anwendung und verfolgen Sie diese auf der server-Seite. So dass, wenn der aktuelle Benutzer sendet die Anforderung zum Zugriff auf eine bestimmte Seite, die token auf der Seite werden auch an der server-Seite. Da die Token sind einzigartig für einen Benutzer für eine bestimmte Sitzung, selbst wenn der Angreifer kann die session-id, kann er Sie entführen die Benutzer-session, als er nicht die gültigen token an den server.
InformationsquelleAutor der Antwort Anandu M Das
@Anandu M Das:
Ich glaube, was Sie können sich auf die Verwendung von session-tokens mit jeder session-ID. Dieser Website erklären kann, die Verwendung von Token, mit den Sitzungen:
https://blog.whitehatsec.com/tag/session-token/
Obwohl Sitzungs-Token sind leicht beschädigt durch einen XSS-Angriff, dies bedeutet nicht, dass Sie nie verwendet werden soll. Ich meine, let ' s face it, wenn etwas war compromisable durch eine Sicherheitslücke auf den server, nicht die Schuld der Methode, die die Schuld der Programmierer, der eingeführt wurde, dass die Schwachstelle (zu markieren Punkte von Hesson und Rook).
Wenn Sie befolgen Sie sorgfältig die Sicherheits-Konventionen und practicies und sichern Sie sich Ihre Website von SQL injection, XSS, und verlangen, dass alle sessions verwaltet werden, die über HTTPS, dann können Sie ganz einfach verwalten des möglichen Angriff von CSRF-Angriffe durch die Verwendung von server-side-tokens, abgelegt innerhalb der Sitzung und aktualisiert, jedesmal, wenn der Benutzer würde dazu führen, dass eine manipulation Ihrer Sitzung (wie ein $_POST übermittelt wird). Auch, NIE die Speicherung von sessions oder deren Inhalte in eine url, egal wie gut Sie denken, Sie sind codiert.
Wenn die Sicherheit der Nutzer ist von größter Bedeutung (was es sollte), die Verwendung von session-tokens erlaubt eine bessere oder erweiterte Funktionalität bereitgestellt werden, ohne Ihre session-Sicherheit.
InformationsquelleAutor der Antwort user253780