Come evitare la condivisione della sessione all'interno della stessa rete

Question

Come evitare la condivisione della sessione all'interno della stessa rete

#1 da (1 voti)
#2 da (0 voti)

-2

Stavo pensando a una situazione per evitare la condivisione di sessioni o il dirottamento, convalidando l'IP che l'utente ha effettuato il login contro l'ip che sta accedendo a una pagina dopo l'accesso. Funzionava finché non ho capito che è possibile quando l'utente proviene da un'altra rete e qualcuno dall'interno della stessa rete ha copiato (o dirottato) il cookie su un'altra macchina. Dopo aver copiato un cookie da una sessione registrata su un'altra macchina, l'altra macchina può accedere all'applicazione senza accesso perché l'ID della sessione è ok e l'IP (quando esce su Internet) è lo stesso.

C'è un modo per evitarlo?

Stavo pensando di crittografare il cookie utilizzando SSL dal server che condivide la chiave come fa per la connessione SSL. In questo modo solo il cliente giusto avrebbe il giusto valore del cookie. (Qui non sto parlando di connessione con SSL ma crittografare il cookie. L'SSL sarà usato per crittografare il contenuto come al solito). Non ho ancora trovato nulla al riguardo.

Direi che la domanda è più simile a "Come posso creare un cookie crittografato basato su ciascun client e il server è l'unico che può decodificare il cookie". Se lo criptico sul server, in base alla mia chiave di crittografia, sarà la stessa crittografia per ogni utente e continuerà a essere copiato.

http cookies session-management session-fixation

posta user3551863 23.04.2014 - 09:36

fonte

2 risposte

Leggi altre domande sui tag http cookies session-management session-fixation

Come decodificare il codice javascript estratto da PDF Come creare una password sicura? [duplicare]

score 1 · Answer 1

Is there any way we can avoid it?

Sì, potresti avere una chiave di sessione a rotazione. cioè il server genererà un nuovo ID di sessione per memorizzare nel cookie ogni n numero di richieste. L'intestazione Set-Cookie verrà inviata una sola volta, quindi se ci sono due browser registrati nella stessa sessione, uno di questi utilizzerà la vecchia sessione non valida. Si potrebbe avere una piccola sovrapposizione in cui entrambe le sessioni sono valide per evitare problemi con richieste di risorse che il browser deve ancora richiedere (ad esempio una richiesta AJAX che è stata appena inviata in attesa di una connessione, mentre il server ha risposto con un nuovo ID al richiesta della pagina principale). Ciò offre un buon bilanciamento dell'usabilità e soddisfa i requisiti della singola sessione in quanto il browser che non riceve il nuovo cookie verrà disconnesso.

Un altro modo per farlo è quello di adottare un metodo più rigoroso, utilizzato da alcune banche. Anziché memorizzare l'ID sessione in un cookie, questo viene memorizzato nella pagina stessa. Ciò garantisce anche che l'utente segua un percorso impostato attraverso il tuo sito e non possa saltare alle pagine fuori sequenza. Il modo in cui funziona è che esiste un campo nascosto all'interno della pagina e ogni azione di navigazione è un POST HTTP alla pagina successiva. per esempio. potresti avere un singolo gestore a https://www.example.com/loggedInAction e ogni modulo POST a questo: -

<form method="post" action="https://www.example.com/loggedInAction">
  <input type="hidden" name="requestId" value="123456" />
  <input type="hidden" name="action" value="navigateToMyAccountPage" />
</form>

L'idea è che l'ID richiesta viene rigenerato dopo ogni azione di navigazione e il server utilizza questo ID richiesta per tenere traccia di ogni sessione. La condivisione delle sessioni non è possibile in quanto l'ID è memorizzato nel modulo piuttosto che nel cookie, sebbene possa essere combinato con un cookie se si desidera mantenere separati l'ID sessione e l'ID richiesta. Se un altro utente ha copiato l'ID della richiesta e modificato la sua richiesta, solo il primo utente potrebbe continuare poiché ogni ID richiesta è scaduto una volta utilizzato. Questo approccio impedirà anche l'uso del pulsante Indietro sul sito, ed è davvero un approccio che deve essere progettato nel sistema sin dall'inizio.

score 0 · Answer 2

I cookie hanno un'opzione per forzare la crittografia. Aggiungi semplicemente secure; all'intestazione del cookie:

Set-Cookie: mycookie=somevalue; path=/securesite/; Expires=12/12/2010; secure; httpOnly;

httpOnly; protegge il cookie da JavaScript.

Vedi Come posso verificare che i miei cookie vengano inviati solo tramite https crittografato e non http?

Tieni presente che l'IP degli utenti potrebbe cambiare durante la sessione potrebbe essere normale. Dispositivo mobile che passa a WLAN o dopo una disconnessione di 24 ore.