Impedisci il dirottamento della sessione, laddove un utente malintenzionato ruba fisicamente l'ID della sessione (cookie) dal browser

I cookie sono lì per evitare l'autenticazione tramite una password per ogni transazione web (altrimenti ogni pagina protetta dovrebbe essere riautentata ogni volta che si accede).

In questo senso i cookie sono indipendenti dalla password.

Devono essere controllati da

• il browser che verifica che la validità non sia scaduta. Il server non dovrebbe mai fare affidamento su questo controllo per i mezzi di sicurezza in quanto il browser è controllato dal client (e può scegliere di non verificare la validità)
• il server che garantisce che il cookie che recupera dal client sia ancora valido in base ai propri criteri (del server) (dovrebbe tenere traccia della validità dei cookie indipendentemente da un possibile "tempo di validità" all'interno del cookie) .

Pertanto il fatto che tu abbia cambiato la password non significa necessariamente che il cookie non è valido. Dovrebbe essere il caso perché il server dovrebbe invalidarli dalla sua parte.
La disconnessione è il modo normale (o meglio dovrebbe essere) per invalidare le sessioni.

Non c'è molto di più oltre (in termini di cookie come meccanismo di autenticazione) - sono un modo possibile per evitare la riautenticazione costante.

Per aggiungere a ciò che @WoJ ha detto, questo comportamento non è l'ideale, ma i siti più grandi spesso forniscono un elenco di sessioni attive, che di solito include l'accesso all'indirizzo IP e offre l'opzione di scadere su sessioni specifiche. Nel caso di più indirizzi IP che accedono contemporaneamente al sito utilizzando gli stessi dettagli di sessione (lo stesso cookie, in questo caso), mi aspetto che un sistema sicuro scada quella sessione e registri entrambe le istanze, chiedendo all'utente di accedere nuovamente .

In generale, scadere tutte le sessioni attive è la procedura migliore quando si modifica una password su un account, ma ci sono casi in cui ciò non viene fatto. Inoltre, anche se questo non è (forse il sito non vuole disconnettere gli utenti dalle sessioni mobili per qualche motivo), l'identificatore di sessione corrente dovrebbe essere cambiato - questo normalmente dovrebbe essere indicato al browser impostando un nuovo cookie.

Esiste una vulnerabilità correlata nota come session-fixation, in cui un cookie specificato non viene modificato all'accesso, quindi un utente malintenzionato che è stato in grado di impostare un cookie in anticipo (presumibilmente attraverso l'accesso alla macchina) può forzare il sito a utilizzare un identificatore di sessione noto, che avrebbe lo stesso risultato: un utente malintenzionato può utilizzare la stessa sessione dell'utente legittimo. Ancora una volta, la correzione è quella di garantire che al momento dell'accesso, l'identificativo di sessione venga rigenerato.

Per inciso, nessuno di questi è click-jacking: si tratta di un attacco distinto.