La sessione "fuoco amichevole" riproduce un problema valido?

3

Ho letto molto su sessioni e sicurezza, cercando di imparare il più possibile prima di scrivere troppo codice. Ho letto di limitare la riproduzione della sessione includendo un timestamp all'interno del cookie o dei dati inviati dal server:

{timeStamp, sessionID, HMAC ({timeStamp, sessionID}, Key)}

limitando il tempo valido con il timestamp e mantenendo tutto su una connessione TLS minimizzerà la riproduzione. Ma cosa succede se l'utente che autentica e riceve questo cookie (o dati) è complice in un attacco con cui invia immediatamente questo cookie ad altri (che ora hanno forse una mezz'ora in base al timestamp). Ovviamente, le credenziali rimarranno limitate a ciò che l'utente iniziale ha il privilegio di fare.

Questa è una vera preoccupazione in natura? C'è un nome per questo?

È realistico, dal momento che questo è TLS, presumere che l'IP del cliente non cambierà, e quindi utilizzare quell'IP come controllo per assicurarsi che questo cookie venga sempre riprodotto dall'IP a cui era originariamente inviato?

    
posta Dave 25.09.2014 - 03:36
fonte

1 risposta

3

La situazione a cui ti stai riferendo si verificherebbe se il cliente fosse compromesso. Questa è una vera preoccupazione, ma in tal caso qualsiasi protezione implementata è banalmente evitabile facendo fare al client compromesso tutto ciò che deve essere fatto. In questo modo puoi eseguire un controllo dell'indirizzo IP, ma in realtà non sarà di grande aiuto.

Detto questo, la struttura dei dati che hai proposto ha una bandiera rossa. Perché stai inviando un timestamp al cliente? Hai fiducia in ciò che dice il cliente? L'ID di sessione dovrebbe mappare a una struttura di dati che controlli, che, tra le altre cose, sa quando scade il timestamp. Non è quindi necessario trasferire tali informazioni al client.

    
risposta data 25.09.2014 - 03:58
fonte

Leggi altre domande sui tag