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

2

Considera un caso, in cui un utente malintenzionato ha accesso fisico al computer dell'utente per 20-30 secondi.
L'utente malintenzionato può utilizzare questo tempo per rubare i cookie dell'utente (ad esempio utilizzando il plug-in EditThisCookie) e inviare i cookie a se stesso (ad esempio tramite Hangouts, Facebook, posta elettronica, ecc.).

L'account dell'utente è compromesso per sempre.
Ho provato personalmente l'esperimento, in cui dico che il cookie di XYZ "X" viene rubato dal mio sistema. Dopo di che cambio la password del mio account XYZ. Ancora l'attaccante può accedere al mio account usando il cookie "X".
Inoltre, a volte è successo con me che i cookie rubati ("X") quando inseriti nel browser non funzionano. Voglio sapere perché questo strano comportamento accade e quale tipo di stato è memorizzato nei cookie. Ho letto della data di scadenza che deve essere memorizzata nel cookie, ma in genere viene memorizzata 1 anno circa dalla data corrente (non sono sicuro di questo fatto però).

Volevo anche sapere se c'è qualche metodo nell'attuale architettura web per prevenire l'attacco di click-jacking dove i cookie sono rubati fisicamente (come descritto sopra).

    
posta aka_007 02.03.2016 - 08:49
fonte

2 risposte

1

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.

    
risposta data 02.03.2016 - 10:18
fonte
1

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.

    
risposta data 02.03.2016 - 10:31
fonte

Leggi altre domande sui tag