it-swarm.com.de

Session-Hijacking verhindern

Wie verhindern Sie, dass mehrere Clients dieselbe Sitzungs-ID verwenden? Ich frage das, weil ich eine zusätzliche Sicherheitsebene hinzufügen möchte, um Sitzungsentführungen auf meiner Website zu verhindern. Wenn ein Hacker irgendwie die Sitzungs-ID eines anderen Benutzers herausfindet und Anforderungen an diese SID stellt, wie kann ich dann feststellen, dass verschiedene Clients eine einzige SID auf dem Server verwenden und dann den Hijack-Versuch ablehnen?

EDIT

Ich habe Gumbos Antwort nach sorgfältiger Überlegung akzeptiert, weil ich zu der Erkenntnis gelangt bin, dass das, was ich verlange, aufgrund der Einschränkungen eines statuslosen HTTP-Protokolls unmöglich ist. Ich habe vergessen, was vielleicht das grundlegendste Prinzip von HTTP ist, und jetzt, wo ich über diese Frage nachdenke, erscheint das ein bisschen trivial.

Lassen Sie mich erläutern, was ich meine:

Nachdem sich Benutzer A auf example.com angemeldet hat, erhält er eine zufällige Sitzungs-ID. Der Einfachheit halber sei "abc123" angegeben. Diese Sitzungs-ID wird auf der Clientseite als Cookie gespeichert und mit einer serverseitigen Sitzung überprüft, um sicherzustellen, dass der angemeldete Benutzer angemeldet bleibt, wenn er von einer Webseite zur anderen wechselt. Dieser Cookie muss natürlich nicht existieren, wenn HTTP nicht zustandslos wäre. Wenn Benutzer B die SID von Benutzer A stiehlt und auf seinem Computer ein Cookie mit dem Wert 'abc123' erstellt, hätte er die Sitzung von Benutzer A erfolgreich entführt, aber der Server kann diese Benutzer B nicht rechtmäßig erkennen Die Anforderung unterscheidet sich von den Anforderungen von Benutzer A. Daher hat der Server keinen Grund, eine Anforderung abzulehnen. Selbst wenn wir die Sitzungen, die bereits auf dem Server aktiv waren, auflisten und versuchen zu sehen, ob jemand auf eine Sitzung zugreift, die bereits aktiv ist, wie können wir dann feststellen, dass ein anderer Benutzer unberechtigt auf die Sitzung und nicht auf denselben Benutzer zugreift der bereits mit einer Sitzungs-ID angemeldet ist, aber lediglich versucht, eine weitere Anfrage zu stellen (dh zu einer anderen Webseite navigieren). Wir können nicht Überprüfen des Benutzeragenten Kann gefälscht werden - aber gut als Tiefenverteidigungsmaßnahme. IP Adresse? Kann sich aus legitimen Gründen ändern - aber anstatt die IP-Adresse überhaupt nicht zu überprüfen, schlage ich vor, die ersten beiden Oktetts der IP-Adresse zu überprüfen, da selbst ein Benutzer in einem Datenplannetzwerk aus legitimen Gründen ständig eine IP-Adresse hat hätte normalerweise nur die letzten zwei Oktette ihrer IP geändert.

Zusammenfassend ist es das zustandslose HTTP, das uns dazu verurteilt, unsere Websites niemals vollständig vor Session-Hijacking schützen zu können. Gute Praktiken (wie sie Gumbo zur Verfügung gestellt hat) sind jedoch gut genug, um eine gute Mehrheit der Session-Angriffe zu verhindern. Der Versuch, Sitzungen vor dem Hijacking zu schützen, indem mehrere Anforderungen derselben SID abgelehnt werden, ist daher einfach lächerlich und würde den gesamten Zweck der Sitzungen zunichte machen.

60
hesson

Leider gibt es keine effektive Möglichkeit, eine Anfrage, die von einem Angreifer stammt, eindeutig einer echten Anfrage zu identifizieren. Da die meisten Eigenschaften, die gegen Maßnahmen wie die IP-Adresse oder die Eigenschaften des Benutzeragenten prüfen, entweder nicht zuverlässig sind (die IP-Adresse kann sich bei mehreren Anforderungen ändern) oder leicht gefälscht werden (z. B. User-Agent - Anforderungsheader) und somit unerwünscht sein False Positives (dh echte vom Benutzer gewechselte IP-Adresse) oder falsche Negative (dh der Angreifer konnte die Anforderung mit demselben User-Agent erfolgreich fälschen).

Daher ist die beste Methode zum Verhindern von Sitzungsentführungen die Sicherstellung, dass ein Angreifer die Sitzungs-ID eines anderen Benutzers nicht ermitteln kann. Das bedeutet, Sie sollten Ihre Anwendung und ihre Sitzungsverwaltung so gestalten, dass (1) ein Angreifer eine gültige Sitzungs-ID nicht mit ausreichend Entropie erraten kann und (2) dass ein Angreifer keine andere Möglichkeit hat, durch bekannte Angriffe eine gültige Sitzungs-ID zu erhalten/Schwachstellen wie das Schnüffeln der Netzwerkkommunikation, Cross-Site Scripting, Durchsickern durch Referer usw.

Das heißt, Sie sollten:

Außerdem sollten Sie die Sitzungs-ID nach einer Änderung des Sitzungsstatus (z. B. Bestätigung der Authentizität nach dem Anmelden oder Änderung der Berechtigungen/Berechtigungen) neu generieren, während die alte ungültig wird (siehe session_regenerate_id-Funktion ). Dies können Sie zusätzlich tun Dies verringert in regelmäßigen Abständen die Zeitspanne für einen erfolgreichen Session-Hijacking-Angriff.

72
Gumbo

Können wir so etwas tun?.

Speichern Sie die Sitzungs-ID in der Datenbank . Speichern Sie auch die Ip-Adresse und das HTTP_USER_AGENT für diese Sitzungs-ID . Wenn nun eine Anforderung an den Server gesendet wird, der die entsprechende Sitzungs-ID enthält, prüfen Sie, von welchem ​​Agenten und von welcher IP es kommt Dein Skript.

Kann dieses Funda zum Laufen bringen, indem Sie eine allgemeine Funktion oder Klasse für eine Sitzung erstellen, sodass jede Anforderung vor der Verarbeitung überprüft wird. Es würde kaum einige Sekunden dauern. Wenn jedoch viele Benutzer Ihre Site besuchen und Sie über eine riesige Datenbank mit Sitzungen verfügen, kann dies ein geringes Leistungsproblem darstellen. Im Vergleich zu anderen Methoden wie => Verwenden von regenerierenden Sitzungen ist dies jedoch sehr sicher.

Beim Wiederherstellen von Sitzungs-IDs besteht wiederum nur eine geringe Chance für Sitzungsentführungen.

angenommen, die Sitzungs-ID des Benutzers wird kopiert, und der Benutzer ist für einige Zeit nicht aktiv oder aktiv, und es wird keine Anforderung an den Server mit der alten Sitzungs-ID gesendet, um eine erneute Generierung zu fordern. Wenn die Sitzungs-ID missbraucht wird, verwendet der Hacker diese Sitzungs-ID und stellt eine Anforderung an den Server mit dieser ID. Der Server antwortet mit der neu erstellten Sitzungs-ID und der Hacker kann die Dienste weiterhin verwenden. Der tatsächliche Benutzer kann nicht mehr arbeiten, da er nicht weiß, wie die regenerierte ID ist und welche Anforderungssitzungs-ID in der Anforderung übergeben werden soll. Völlig verschwunden.

Bitte korrigieren Sie mich, wenn ich mich irgendwo irre.

4
kanchan

Es gibt viele Standardabwehrmechanismen gegen Session-Hijacking. Eine davon ist, jede Sitzung einer einzigen IP-Adresse zuzuordnen.

Andere Schemen kann eine HMAC verwenden, die generiert wurde von:

  • die Netzwerkadresse der IP des Clients
  • der vom Client gesendete User-Agent-Header
  • die SID
  • ein geheimer Schlüssel, der auf dem Server gespeichert ist

Der Grund dafür, dass nur die Netzwerkadresse der IP-Adresse verwendet wird, ist der Fall, dass sich der Benutzer hinter einem öffentlichen Proxy befindet. In diesem Fall kann sich die IP-Adresse bei jeder Anforderung ändern, die Netzwerkadresse bleibt jedoch gleich.

Um wirklich sicher zu sein, müssen Sie natürlich SSL für alle Anfragen erzwingen, damit die SID nicht von potenziellen Angreifern abgefangen werden kann. Dies ist jedoch nicht bei allen Sites der Fall (:: cough :: Stack Overflow :: cough ::).

2
Lèse majesté

Eine der einfachen Implementierungen kann durchgeführt werden, indem als protokollierte Benutzer eine Tabelle in der Datenbank erstellt wird. Bei der Anmeldung wird diese Tabelle mit dem Benutzernamen und seiner SID aktualisiert. Dadurch werden andere Anmeldungen als derselbe Benutzer verhindert. Führen Sie einfach eine einfache Abfrage aus, die die eingeloggten Daten in der Datenbank löscht. Diese kann auch verwendet werden, um den auf der ur-Website angemeldeten Benutzer gleichzeitig zu verfolgen.

1
Ratan Kumar

Wenn Sie im Browser ein Session-Cookie setzen, wird dieses Cookie natürlich in der Anfrage gesendet. Wenn nun die Anforderung kommt, überprüft der Server die Sitzungs-ID in der Datenbank und gewährt den Zugriff. Um zu verhindern, dass nur der Agent und die IP-Adresse gespeichert werden, muss der Server vor der Überprüfung sicherstellen, dass der Sitzungszugriff dem eindeutigen Client gewährt wird und nicht die eindeutige Sitzungs-ID, die entführt werden kann.

1
kanchan

In meiner Ansicht können Sie die Sitzungs-ID in der Datenbank speichern, wenn sich die Benutzer anmelden, und alle Benutzer auf die gleiche prüfen, bevor Sie sich anmelden. Löschen Sie dieselbe Sitzungs-ID, die Sie bei der Abmeldung von Benutzern in der Datenbank gespeichert haben. Sie können die Sitzungs-ID von jedem einzelnen Benutzer leicht herausfinden, sonst kann ich Ihnen helfen.

1
Sk MiRaj

Ich kenne den Kodierabschnitt nicht gut. Also kann ich Ihnen einen Algorithmus mitteilen, um dies zu tun. Festlegen von Einstellungen wie SSL oder Einstellen des Sitzungscookies auf Sicherheit und httpOnly funktioniert nicht, wenn ein Benutzer die Sitzungs-ID aus einem LAN-Netzwerk herausfindet (Bereitgestellte Benutzer und Angreifer befinden sich im selben LAN). 

Sie können also, sobald sich der Benutzer erfolgreich bei der Anwendung anmeldet, für jede einzelne Seite der Webanwendung ein eindeutiges Token setzen und dies auf der Serverseite nachverfolgen. Wenn also der gültige Benutzer die Anforderung zum Zugriff auf eine bestimmte Seite sendet, wird auch das Token dieser Seite an die Serverseite gesendet. Da die Token für einen Benutzer für eine bestimmte Sitzung eindeutig sind, kann der Angreifer die Benutzersitzung nicht hijacken, auch wenn der Angreifer die Sitzungs-ID abrufen kann, da er dem Server kein gültiges Token zur Verfügung stellen kann. 

0
Anandu M Das

Sitzungsentführung ist eine ernsthafte Bedrohung. Sie muss mithilfe einer sicheren Socket-Ebene für erweiterte Anwendungen, die Transaktionen umfassen, oder mithilfe einfacher Techniken wie der Verwendung von Cookies, Sitzungs-Timeouts und der Wiederherstellung von IDs usw., wie oben erläutert, gehandhabt werden.
Als das Internet geboren wurde, war die HTTP-Kommunikation auf Staatenlosigkeit ausgelegt. Das heißt, eine Verbindung zwischen zwei Entitäten besteht nur für den kurzen Zeitraum, der erforderlich ist, damit eine Anforderung an den Server gesendet und die resultierende Antwort an den Client zurückgegeben wird. Hier sind einige Methoden, denen Hacker folgen, um die Sitzung zu entführen

  • Netzwerk-Abhören
  • Ahnungslose Belichtung
  • Weiterleitung, Proxies und Phishing
  • Reverse-Proxies

Immer SSL empfehlen Secure Sockets Layer
Verwenden Sie cookies auch, um ini_set () - Anweisungen zu Beginn Ihres Skripts zu befolgen, um globale Einstellungen in der php.ini zu überschreiben:

ini_set( 'session.use_only_cookies', TRUE );                
ini_set( 'session.use_trans_sid', FALSE );

Verwenden Sie Session Timeouts und Session Regenerate ID

<?php
// regenerate session on successful login
if ( !empty( $_POST['password'] ) && $_POST['password'] === $password )         
{       
 // if authenticated, generate a new random session ID
  session_regenerate_id();

 // set session to authenticated
  $_SESSION['auth'] = TRUE;

 // redirect to make the new session ID live

 header( 'Location: ' . $_SERVER['SCRIPT_NAME'] );
}                   
// take some action
?>
0

@Anandu M Das:

Ich glaube, worauf Sie sich beziehen, ist die Verwendung von Session-Token mit jeder Session-ID. Diese Site kann die Verwendung von Token mit Sitzungen erklären:

https://blog.whitehatsec.com/tag/session-token/

Obwohl Session-Token durch einen XSS-Angriff leicht gefährdet werden, bedeutet dies nicht, dass sie niemals verwendet werden sollten. Ich meine, seien wir ehrlich, wenn etwas durch eine Sicherheitslücke auf dem Server gefährdet werden konnte, ist es nicht die Schuld der Methode, es ist die Schuld des Programmierers, der diese Sicherheitslücke eingeführt hat (um Punkte von Hesson und Rook hervorzuheben).

Wenn Sie die richtigen Sicherheitskonventionen und -praktiken einhalten und Ihre Site vor SQL-Injection und XSS schützen und alle Sitzungen über HTTPS verwalten müssen, können Sie den möglichen Angriff von CSRF mithilfe von serverseitigen Token, die in der Sitzung gespeichert sind, problemlos verwalten. und jedes Mal aktualisiert, wenn der Benutzer eine Manipulation an seiner Sitzung verursacht (wie das Senden eines $ _POST). Speichern Sie NIEMALS Sitzungen oder deren Inhalte in einer URL, unabhängig davon, wie gut Sie denken, dass sie verschlüsselt sind.

Wenn die Sicherheit Ihrer Benutzer von größter Bedeutung ist (wie es sein sollte), können durch die Verwendung von Sitzungstoken bessere oder erweiterte Funktionen bereitgestellt werden, ohne dass die Sitzungssicherheit beeinträchtigt wird.

0
user253780