Ho avuto questa funzionalità (protezione csrf) da un po 'di tempo. La cosa che non mi è mai piaciuta è che ha salvato i token csrf nel file di sessione. Anche se potrebbe non essere un problema reale, lo vedo come un dolore perché alla fine i token potrebbero accumularsi, quindi ho bisogno di utilizzare un meccanismo gc e tenere traccia di ciò che è stato emesso quando e tutto sembra troppo per me.
Quindi ho passato gli ultimi due giorni a migliorare questa "imperfezione" ed ecco cosa ho scoperto. Non pubblicherò alcun codice reale, spiegherò solo l'idea.
Quando viene emesso un modulo, per impostazione predefinita viene generato un token. Il token è costituito da alcuni dati univoci per l'utente, come ID sessione o ID utente, combinati con la stringa datetime corrente in formato YmdHi
. Tutto questo è crittografato usando password_hash
e ho pensato di offuscare ulteriormente l'hash scambiando parti di esso ma non l'ho ancora fatto.
La convalida è stata un po 'complicata e si è rivelata piuttosto deludente. Per convalidare un token, creo un ciclo che raccoglie le stesse informazioni sull'utente con la data e sottrae 1 minuto per ogni iterazione. Il numero di iterazioni è uguale alla quantità di minuti per cui il token è valido, che non è memorizzato nel token, quindi tutti i token devono essere validi per lo stesso intervallo di tempo, che non mi sembra ancora uno svantaggio.
Voglio chiederti se vedi eventuali difetti e exploit con questo concetto.
L'unico problema possibile è che i token non sono effettivamente conservati dal server, quindi teoricamente chiunque può assemblare un token valido, tuttavia penso che sia altamente improbabile che qualcuno possa passare giorni a raccogliere i token e che capiti di avere un super-computer nel loro seminterrato per eseguire analisti statistici, che non garantisce nuovamente che sarebbero in grado di decifrare la crittografia.
In ogni caso, suppongo che dovrei smettere di esporre la mia incompetenza e lasciare che le persone intelligenti decidano cosa succede.