Questo schema di sessione non basato sui cookie è orribilmente vulnerabile ad alcuni attacchi?

In pratica stai provando a memorizzare le informazioni di sessione lato client - non memorizzate in modo permanente , ma memorizzate comunque. Questo può essere fatto, ma è delicato.

Il modello di base è il seguente:

• Un client autenticato riceve un valore generato casualmente, ad esempio un "ID di sessione". Qualcosa di abbastanza grande che provare valori casuali avrebbe solo una probabilità trascurabile di colpire un ID di sessione esistente, così che non è possibile "rubare" una sessione. (16 byte casuali sono sufficienti, se usi un PRNG strong.)

• L'ID di sessione viene inviato al client e il client lo rimanda per ogni richiesta.

• Il server mantiene i dati specifici del client in un database (o mappa in memoria) indicizzati dall'ID di sessione, inclusi cose come la data e l'ora dell'ultima richiesta dal client.

Da questo modello, è possibile scaricare alcuni dei requisiti di archiviazione sul client. Questo è ciò che suggerisci: con l'ID di sessione, invii altri dati al client, come un blob opaco che il client dovrebbe rimandare invariato alla successiva richiesta . Permettetemi di evidenziare i punti importanti:

• "dati al client" : questi dati diventano quindi disponibili per il client; questo può o non può essere un problema, a seconda dei dati esatti. C'è un piccolo problema nel permettere all'utente di imparare il proprio nome o la data della sua ultima richiesta, dal momento che avrebbe potuto indovinare da solo. Tuttavia, in generale, lo strumento è crittografia simmetrica , con una chiave simmetrica scelta dal server in modo casuale e non divulga mai alcun cliente. Tieni presente che questo può sollevare problemi su server multi-front-end e server che si riavviano (a seconda del modello di bilanciamento del carico, potresti dover condividere la chiave tra i frontend).

• "il client deve rispedire" : cosa succede se il cliente, per un capriccio, decide non di rimandarlo indietro? Oppure, invece di un capriccio, la connessione del cliente muore? (Le interruzioni di corrente do avvengono.) Se il server mantiene le strutture in memoria indicizzate dall'ID di sessione, allora è necessario un qualche tipo di pulizia automatica al timeout. Dovrai quindi più o meno forzatamente "disconnettere" i client inattivi o farli inviare regolarmente una richiesta fittizia.

• "invariato" : il client può provare a modificare il suo blob, ad es. cambia la parte "nome utente". Contrariamente a quanto sembri assumere, la crittografia non protegge contro l'alterazione. Alcuni tipi di crittografia potrebbero rendere l'attività un po 'a disagio o sfocata per l'autore dell'attacco, ma la crittografia non è stata pensata per questo, e in questo modo non otterrai un livello di protezione appropriato. Quello che vuoi è un codice di autenticazione dei messaggi , che può essere visualizzato come una sorta di "checksum con chiave". Un MAC ti permetterà di rilevare, lato server, alterazioni indesiderate - a meno che la "modifica" non sia la sostituzione del blob con un altro blob completo inviato dal server allo stesso o ad un altro utente.

  Un MAC ha bisogno dello stesso tipo di chiave rispetto alla crittografia simmetrica, quindi solleva gli stessi problemi sulla gestione delle chiavi. Inoltre, se si desidera disporre di un e MAC per crittografare, si sarà estremamente tentati di utilizzare la stessa chiave per entrambi gli usi. Questa non è una buona idea. Se si desidera crittografare e disporre di un MAC, è necessario utilizzare una modalità dedicata come EAX , per la quale le persone intelligenti hanno già scoperto e disattivato le insidie inerenti a tale impresa; oppure, potresti provare a realizzare una costruzione fatta in casa e lasciare che il tuo sistema si unisca all'orda di sistemi fatti in casa che non sono riusciti a essere sicuri quanto il loro progettista aveva inizialmente sognato.

• "la sua prossima richiesta" : il client può inviare blob out-of-order, duplicando un vecchio valore blob, eventualmente mescolando blob da due connessioni parallele. Varie questioni possono sorgere da tali giochi. Il blob rappresenta la memoria del tuo server: si tratta di dati che ti fidi del client perché il server non desidera ricordarlo da solo; corrispondentemente, nulla impedisce al client di fare in modo che il server lo "dimentichi" o "rewind" la memoria del server. Né il MAC né la crittografia possono risolverlo. A seconda dell'applicazione, potrebbe trattarsi o meno di un problema, ma è probabile che lo sia.

Infine, scaricare i dati sul client significa che stai scambiando la larghezza di banda della rete per le dimensioni della RAM: salvi alcuni byte di RAM, ma hai più dati da inviare e ricevere. Economicamente parlando, non sono sicuro che si tratti di una mossa intelligente.

KISS - Keep It Simple, S_ _ _ (completa ciò che vuoi).

Passa solo un ID di sessione al client. Verificare quell'ID di sessione sul lato server. Il server dovrebbe mappare a chi appartiene l'ID di sessione. Il server dovrebbe essere responsabile della scadenza dell'ID di sessione.

Sotto il tuo sistema attuale, non è chiaro se un utente può cambiare la propria identità cambiando il nome utente. Inoltre, non è chiaro cosa succederà se modificano i timestamp.

Althoug La risposta di Tom Leek è già stata accettata, ci sono un paio di punti che non affronta.

Come descritto

1. non c'è nulla da evitare contro replay di terze parti e XSRF
2. l'identificatore di sessione è bookmarkable / facilmente trasferibile
3. richiederà una grande quantità di codice personalizzato (più codice = più errori = meno sicuro) per gestire la sessione
4. per i cookie puoi facilmente limitare un ID di sessione per non essere accessibile a javascript e / o essere utilizzato solo per SSL e / o limitare a un percorso specifico - quindi a meno che non aggiunga molto codice, la superficie di attacco è molto più grande
5. richiederà un sacco di codice per popolare ogni possibile metodo di navigazione tra le pagine - Il meccanismo di gestione delle sessioni di PHP fornisce un meccanismo per propagare un ID di sessione tramite le variabili GET CGI - ma nessuno lo usa perché si imbattono in problemi con javascript, moduli POST , reindirizzamento .... oltre agli altri problemi sopra descritti.

Se stai seguendo il percorso dell'utilizzo di un valore lato client per fare riferimento ai dati sul lato server, non utilizzare (a) la crittografia simmetrica per generare l'handle - se il tuo segreto è mai compromesso l'intero sistema è compromesso. Utilizzare un valore casuale e mantenere una tabella di ricerca server. (Questo vale indipendentemente da dove si memorizza l'ID di sessione).

Solo non pensare nemmeno a provare questo

The session token is an encrypted string...

Se utilizzi una buona, casuale, private (= non parte dei dati trasmessi) salla e aggiorna (ricodifica) la stringa criptata più di frequente (per impedire "replay" ), potrebbe essere fatto.

Ma da un punto di vista della sicurezza, mi vengono i brividi lungo la schiena fino a pensare a qualcuno che la implementa in quel modo. Stai mostrando i dati del mondo che potresti e dovresti proteggere.

In altre parole: non farlo così!

Lasciatemi solo aggiungere tre semplici domande:

1. Dato che potenzialmente stai mostrando i dati crittografati a chiunque in pubblico, quanto sono sicuri i tuoi dati crittografati quando si tratta di decodificare la tua implementazione crittografica?
2. Che dire degli attacchi a forza bruta e in che modo prevedi di difenderti da quelli che il tuo sistema non può sapere se i dati trasmessi sono stati incasinati (esempio: token ricodificato contenente diversi dati come un altro IP)?
3. Lo sai che - fornendo il salt con i dati criptati - stai effettivamente fornendo parte della chiave necessaria per decodificare i dati che stai trasmettendo?

Quindi, uno dei motivi più importanti per non fare ciò che fai è che non puoi verificare la validità dei dati del tuo token o che sono contenuti, dati criptati.

Inoltre, fornire il sale che stai usando insieme ai tuoi dati criptati è un assoluto "no-no" perché un tale sale deve essere mantenuto assolutamente privato. È "parte del mix" che dovrebbe effettivamente rendere più difficile la forzatura bruta. Pubblicare il sale con i dati crittografati svuota lo scopo del sale e lo rende facile come se non ci fosse sale!

Alla fine, devi sempre ricordarti che le procedure di crittografia e / o sicurezza implementate in modo errato o sbagliato non saranno mai in grado di proteggerti come previsto . Da quanto ho letto nella descrizione che viene fornita con la tua domanda, mi dispiace dire che stai sbagliando in diverse aree.