Was ist der beste Weg, um Session-Hijacking zu verhindern?
https://stackoverflow.com/questions/22880
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Dies betrifft insbesondere die Verwendung eines Client-Sitzungscookies zur Identifizierung einer Sitzung auf dem Server.
Ist die Verwendung der SSL/HTTPS-Verschlüsselung für die gesamte Website die beste Lösung, und Sie haben die beste Garantie, dass kein Man-in-the-Middle-Angriff in der Lage sein wird, ein vorhandenes Client-Sitzungs-Cookie auszuspionieren?
Und vielleicht ist es am zweitbesten, eine Art Verschlüsselung für den Sitzungswert selbst zu verwenden, der in Ihrem Sitzungscookie gespeichert ist?
Wenn ein böswilliger Benutzer physischen Zugriff auf eine Maschine hat, kann er dennoch im Dateisystem nach einem gültigen Sitzungscookie suchen und dieses zum Kapern einer Sitzung verwenden?
Lösung
Das Verschlüsseln des Sitzungswerts hat keine Auswirkung.Das Sitzungscookie ist bereits ein beliebiger Wert. Durch die Verschlüsselung wird lediglich ein weiterer beliebiger Wert generiert, der ausgespuckt werden kann.
Die einzig wirkliche Lösung ist HTTPS.Wenn Sie nicht auf Ihrer gesamten Website SSL verwenden möchten (vielleicht haben Sie Bedenken hinsichtlich der Leistung), können Sie möglicherweise darauf verzichten, die sensiblen Bereiche nur durch SSL zu schützen.Stellen Sie dazu zunächst sicher, dass Ihre Anmeldeseite HTTPS ist.Wenn sich ein Benutzer anmeldet, setzen Sie zusätzlich zum regulären Sitzungscookie ein sicheres Cookie (das heißt, der Browser überträgt es nur über eine SSL-Verbindung).Wenn ein Benutzer dann einen Ihrer „sensiblen“ Bereiche besucht, leiten Sie ihn zu HTTPS um und prüfen Sie, ob dieses sichere Cookie vorhanden ist.Ein echter Benutzer wird es haben, ein Session-Hijacker jedoch nicht.
BEARBEITEN:Diese Antwort wurde ursprünglich im Jahr 2008 verfasst.Wir schreiben das Jahr 2016 und es gibt keinen Grund, nicht auf Ihrer gesamten Website SSL zu verwenden.Kein Klartext-HTTP mehr!
Andere Tipps
Das SSL hilft nur bei Sniffing-Angriffen.Wenn ein Angreifer Zugriff auf Ihren Computer hat, gehe ich davon aus, dass er auch Ihr sicheres Cookie kopieren kann.
Stellen Sie zumindest sicher, dass alte Kekse mit der Zeit ihren Wert verlieren.Selbst ein erfolgreicher Hijaking-Angriff wird vereitelt, wenn das Cookie nicht mehr funktioniert.Wenn der Benutzer ein Cookie von einer Sitzung hat, bei der er sich vor mehr als einem Monat angemeldet hat, bitten Sie ihn, sein Passwort erneut einzugeben.Stellen Sie sicher, dass die alte Sitzungs-UUID nie wieder verwendet werden kann, wenn ein Benutzer auf den „Abmelden“-Link Ihrer Website klickt.
Ich bin mir nicht sicher, ob diese Idee funktionieren wird, aber hier ist:Fügen Sie Ihrem Sitzungscookie eine Seriennummer hinzu, möglicherweise eine Zeichenfolge wie diese:
SessionUUID, Seriennummer, aktuelles Datum/Uhrzeit
Verschlüsseln Sie diese Zeichenfolge und verwenden Sie sie als Sitzungscookie.Ändern Sie regelmäßig die Seriennummer – vielleicht, wenn das Cookie 5 Minuten alt ist, und geben Sie das Cookie dann erneut aus.Sie könnten es sogar bei jedem Seitenaufruf erneut ausgeben, wenn Sie möchten.Notieren Sie sich serverseitig die letzte Seriennummer, die Sie für diese Sitzung vergeben haben.Wenn jemand jemals ein Cookie mit der falschen Seriennummer sendet, bedeutet dies, dass ein Angreifer möglicherweise ein Cookie verwendet, das er zuvor abgefangen hat. Machen Sie daher die Sitzungs-UUID ungültig und fordern Sie den Benutzer auf, sein Passwort erneut einzugeben und dann erneut ein neues Cookie auszugeben.
Denken Sie daran, dass Ihr Benutzer möglicherweise über mehr als einen Computer verfügt und daher möglicherweise mehr als eine aktive Sitzung hat.Tun Sie nichts, was sie dazu zwingt, sich jedes Mal erneut anzumelden, wenn sie zwischen Computern wechseln.
Haben Sie darüber nachgedacht, ein Buch über PHP-Sicherheit zu lesen?Sehr empfehlenswert.
Ich habe mit der folgenden Methode für nicht SSL-zertifizierte Websites großen Erfolg gehabt.
Verbieten Sie mehrere Sitzungen unter demselben Konto und stellen Sie sicher, dass Sie dies nicht ausschließlich anhand der IP-Adresse überprüfen.Überprüfen Sie lieber anhand des bei der Anmeldung generierten Tokens, das mit der Benutzersitzung in der Datenbank gespeichert wird, sowie anhand der IP-Adresse, HTTP_USER_AGENT usw
Die Verwendung von relationsbasierten Hyperlinks erzeugt einen Link (z. http://example.com/secure.php?token=2349df98sdf98a9asdf8fas98df8 .
- Beim Neuladen werden mehrere Überprüfungen durchgeführt.
- Ursprungs-IP-Adresse
- HTTP_USER_AGENT
- Sitzungstoken
- Du verstehst, worauf es ankommt.
Sitzungsauthentifizierungscookie mit kurzer Lebensdauer.Wie oben angegeben, ist ein Cookie mit einer sicheren Zeichenfolge, die einen direkten Hinweis auf die Gültigkeit der Sitzung darstellt, eine gute Idee.Lassen Sie es alle x Minuten ablaufen, stellen Sie das Token erneut aus und synchronisieren Sie die Sitzung erneut mit den neuen Daten.Wenn die Daten nicht übereinstimmen, melden Sie den Benutzer entweder ab oder lassen Sie ihn seine Sitzung erneut authentifizieren.
Ich bin keineswegs ein Experte auf diesem Gebiet, ich habe ein wenig Erfahrung in diesem speziellen Thema und hoffe, dass einiges davon irgendjemandem da draußen hilft.
// Collect this information on every request
$aip = $_SERVER['REMOTE_ADDR'];
$bip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$agent = $_SERVER['HTTP_USER_AGENT'];
session_start();
// Do this each time the user successfully logs in.
$_SESSION['ident'] = hash("sha256", $aip . $bip . $agent);
// Do this every time the client makes a request to the server, after authenticating
$ident = hash("sha256", $aip . $bip . $agent);
if ($ident != $_SESSION['ident'])
{
end_session();
header("Location: login.php");
// add some fancy pants GET/POST var headers for login.php, that lets you
// know in the login page to notify the user of why they're being challenged
// for login again, etc.
}
Dadurch werden „kontextbezogene“ Informationen über die Sitzung des Benutzers erfasst, Informationen, die sich während der Dauer einer einzelnen Sitzung nicht ändern sollten.Ein Benutzer wird nicht gleichzeitig in den USA und in China an einem Computer sitzen, oder?Wenn sich also die IP-Adresse innerhalb derselben Sitzung plötzlich ändert, deutet dies stark auf einen Session-Hijacking-Versuch hin. Sie sichern die Sitzung, indem Sie die Sitzung beenden und den Benutzer zu einer erneuten Authentifizierung zwingen.Dadurch wird der Hackversuch vereitelt, der Angreifer wird außerdem gezwungen, sich anzumelden, anstatt Zugriff auf die Sitzung zu erhalten.Benachrichtigen Sie den Benutzer über den Versuch (verstärken Sie ihn ein wenig) und vola, leicht verärgerter + informierter Benutzer und seine Sitzung/Informationen sind geschützt.
Wir fügen User Agent und X-FORWARDED-FOR hinzu, um unser Bestes zu geben, um die Einzigartigkeit einer Sitzung für Systeme hinter Proxys/Netzwerken zu erfassen.Möglicherweise können Sie weitere Informationen verwenden, seien Sie also kreativ.
Es ist nicht 100 %, aber es ist verdammt effektiv.
Sie können noch mehr tun, um Sitzungen zu schützen, sie ablaufen zu lassen und sie ggf. zu einer erneuten Anmeldung zu zwingen, wenn sie eine Website verlässt und zurückkommt.Sie können erkennen, dass ein Benutzer die Seite verlässt und wieder zurückkommt, indem Sie einen leeren HTTP_REFERER erfassen (die Domain wurde in die URL-Leiste eingegeben) oder prüfen, ob der Wert im HTTP_REFERER Ihrer Domain entspricht oder nicht (der Benutzer hat auf einen externen/manipulierten Link geklickt, um zu Ihrer Domain zu gelangen). Website).
Lassen Sie Sitzungen ablaufen, lassen Sie sie nicht auf unbestimmte Zeit gültig bleiben.
Verlassen Sie sich nicht auf Cookies, sie können gestohlen werden, sie sind einer der Angriffsvektoren für Session-Hijacking.
Probieren Sie das unter beschriebene Secure Cookie-Protokoll aus Das Artikel von Liu, Kovacs, Huang und Gouda:
Wie im Dokument angegeben:
Ein sicheres Cookie -Protokoll, das zwischen einem Client und einem Server läuft, muss die folgenden vier Dienste bereitstellen:Authentifizierung, Vertraulichkeit, Integrität und Anti-Replay.
Was die einfache Bereitstellung betrifft:
In Bezug auf die Effizienz beinhaltet unser Protokoll keine Datenbank -Suche oder Kryptographie für öffentliche Schlüssel.In Bezug auf die Bereitstellung kann unser Protokoll auf einem vorhandenen Webserver problemlos bereitgestellt werden und erfordert keine Änderungen der Internet -Cookie -Spezifikation.
Zusamenfassend:Es ist sicher, leicht und funktioniert für mich einfach großartig.
Es gibt keine Möglichkeit, Session-Hijaking zu 100 % zu verhindern, aber mit einem bestimmten Ansatz können wir die Zeit verkürzen, die ein Angreifer für das Hijaking der Sitzung benötigt.
Methode zur Verhinderung von Session Hijaking:
1 – Sitzung immer mit SSL-Zertifikat verwenden;
2 – Sitzungscookie nur senden, wenn „httponly“ auf „true“ gesetzt ist (Javascript am Zugriff auf Sitzungscookies hindern)
2 – Sitzungsneugenerierungs-ID beim Anmelden und Abmelden verwenden (Hinweis:Verwenden Sie die Sitzungsneugenerierung nicht bei jeder Anfrage, da Sie bei aufeinanderfolgenden Ajax-Anfragen die Möglichkeit haben, mehrere Sitzungen zu erstellen.)
3 – Legen Sie ein Sitzungszeitlimit fest
4 – Browser-Benutzeragenten in einer $_SESSION-Variablen speichern und bei jeder Anfrage mit $_SERVER['HTTP_USER_AGENT'] vergleichen
5 – Setzen Sie ein Token-Cookie und setzen Sie die Ablaufzeit dieses Cookies auf 0 (bis der Browser geschlossen wird).Generieren Sie den Cookie-Wert für jede Anfrage neu. (Für Ajax-Anfragen kein Token-Cookie neu generieren).EX:
//set a token cookie if one not exist
if(!isset($_COOKIE['user_token'])){
//generate a random string for cookie value
$cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));
//set a session variable with that random string
$_SESSION['user_token'] = $cookie_token;
//set cookie with rand value
setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
}
//set a sesison variable with request of www.example.com
if(!isset($_SESSION['request'])){
$_SESSION['request'] = -1;
}
//increment $_SESSION['request'] with 1 for each request at www.example.com
$_SESSION['request']++;
//verify if $_SESSION['user_token'] it's equal with $_COOKIE['user_token'] only for $_SESSION['request'] > 0
if($_SESSION['request'] > 0){
// if it's equal then regenerete value of token cookie if not then destroy_session
if($_SESSION['user_token'] === $_COOKIE['user_token']){
$cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));
$_SESSION['user_token'] = $cookie_token;
setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
}else{
//code for session_destroy
}
}
//prevent session hijaking with browser user agent
if(!isset($_SESSION['user_agent'])){
$_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
}
if($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']){
die('session hijaking - user agent');
}
Notiz:REGENURATE TOKEN COOKIE NICHT MIT AJAX ANFORMERNISSEMINDERUNG:Der obige Code ist ein Beispiel.Notiz:Wenn sich Benutzer abmelden, müssen sowohl das Cookie-Token als auch die Sitzung zerstört werden
6 – Es ist kein guter Ansatz, die Benutzer-IP zur Verhinderung von Session-Hijaking zu verwenden, da sich die IP-Adresse einiger Benutzer bei jeder Anfrage ändert.DAS BETRIFFT GÜLTIGE BENUTZER
7 – Ich persönlich speichere Sitzungsdaten in der Datenbank, es liegt an Ihnen, welche Methode Sie wählen
Wenn Sie einen Fehler in meinem Ansatz finden, korrigieren Sie mich bitte.Wenn Sie weitere Möglichkeiten haben, Session-Hyjaking zu verhindern, teilen Sie mir dies bitte mit.
Stellen Sie sicher, dass Sie keine inkrementierenden Ganzzahlen für Sitzungs-IDs verwenden.Viel besser ist es, eine GUID oder eine andere lange, zufällig generierte Zeichenfolge zu verwenden.
Es gibt viele Möglichkeiten, Schutz vor Session-Hijacking zu schaffen, doch alle verringern entweder die Benutzerzufriedenheit oder sind nicht sicher.
IP- und/oder X-FORWARDED-FOR-Prüfungen.Diese funktionieren und sind ziemlich sicher ...Aber stellen Sie sich den Schmerz der Benutzer vor.Sie kommen in ein Büro mit WLAN, erhalten eine neue IP-Adresse und verlieren die Sitzung.Muss mich noch einmal anmelden.
Benutzeragentenprüfungen.Wie oben, es ist eine neue Browserversion verfügbar und Sie verlieren eine Sitzung.Darüber hinaus sind diese wirklich leicht zu „hacken“.Für Hacker ist es trivial, gefälschte UA-Strings zu versenden.
localStorage-Token.Generieren Sie beim Anmelden ein Token, speichern Sie es im Browserspeicher und speichern Sie es in einem verschlüsselten Cookie (verschlüsselt auf der Serverseite).Dies hat keine Nebenwirkungen für den Benutzer (localStorage bleibt auch bei Browser-Upgrades bestehen).Es ist nicht so sicher – es geht einfach um Sicherheit durch Dunkelheit.Darüber hinaus könnten Sie JS eine gewisse Logik (Verschlüsselung/Entschlüsselung) hinzufügen, um es weiter zu verschleiern.
Cookie-Neuausstellung.Dies ist wahrscheinlich der richtige Weg.Der Trick besteht darin, jeweils nur einem Client die Verwendung eines Cookies zu erlauben.Für aktive Benutzer werden die Cookies also jede Stunde oder weniger neu ausgegeben.Ein altes Cookie wird ungültig, wenn ein neues ausgegeben wird.Hacks sind immer noch möglich, aber viel schwieriger durchzuführen – entweder dem Hacker oder dem gültigen Benutzer wird der Zugriff verweigert.
Nehmen wir an, dass sich Client und Server während der Anmeldephase auf einen geheimen Salt-Wert einigen können.Danach stellt der Server bei jedem Update einen Zählwert bereit und erwartet vom Client, dass er mit dem Hash des (geheimen Salt + Count) antwortet.Der potenzielle Hijacker hat keine Möglichkeit, an diesen geheimen Salt-Wert zu gelangen und kann daher nicht den nächsten Hash generieren.
AFAIK, auf das Sitzungsobjekt kann auf dem Client nicht zugegriffen werden, da es auf dem Webserver gespeichert ist.Die Sitzungs-ID wird jedoch als Cookie gespeichert und ermöglicht es dem Webserver, die Sitzung des Benutzers zu verfolgen.
Um Sitzungs-Hijacking mithilfe der Sitzungs-ID zu verhindern, können Sie im Sitzungsobjekt eine Hash-Zeichenfolge speichern, die aus einer Kombination aus zwei Attributen, Remote-Adresse und Remote-Port, erstellt wird und auf die auf dem Webserver im Anforderungsobjekt zugegriffen werden kann.Diese Attribute verknüpfen die Benutzersitzung mit dem Browser, bei dem sich der Benutzer angemeldet hat.
Wenn sich der Benutzer über einen anderen Browser oder einen Inkognito-Modus auf demselben System anmeldet, bleibt die IP-Adresse dieselbe, der Port ist jedoch unterschiedlich.Daher wird dem Benutzer beim Zugriff auf die Anwendung vom Webserver eine andere Sitzungs-ID zugewiesen.
Unten ist der Code, den ich implementiert und getestet habe, indem ich die Sitzungs-ID von einer Sitzung in eine andere kopiert habe.Es funktioniert ganz gut.Wenn es eine Lücke gibt, teilen Sie mir mit, wie Sie diese simuliert haben.
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
HttpSession session = request.getSession();
String sessionKey = (String) session.getAttribute("sessionkey");
String remoteAddr = request.getRemoteAddr();
int remotePort = request.getRemotePort();
String sha256Hex = DigestUtils.sha256Hex(remoteAddr + remotePort);
if (sessionKey == null || sessionKey.isEmpty()) {
session.setAttribute("sessionkey", sha256Hex);
// save mapping to memory to track which user attempted
Application.userSessionMap.put(sha256Hex, remoteAddr + remotePort);
} else if (!sha256Hex.equals(sessionKey)) {
session.invalidate();
response.getWriter().append(Application.userSessionMap.get(sessionKey));
response.getWriter().append(" attempted to hijack session id ").append(request.getRequestedSessionId());
response.getWriter().append("of user ").append(Application.userSessionMap.get(sha256Hex));
return;
}
response.getWriter().append("Valid Session\n");
}
Ich habe den SHA-2-Algorithmus verwendet, um den Wert anhand des Beispiels unter zu hashen SHA-256-Hashing und andere
Ich freue mich auf Eure Kommentare.
Um das Risiko zu verringern, können Sie der Sitzung auch die Ursprungs-IP zuordnen.Auf diese Weise muss sich ein Angreifer im selben privaten Netzwerk befinden, um die Sitzung nutzen zu können.
Die Überprüfung von Referrer-Headern kann ebenfalls eine Option sein, diese lassen sich jedoch leichter fälschen.
Schützen Sie sich durch:
$ip=$_SERVER['REMOTE_ADDER'];
$_SESSEION['ip']=$ip;
