Che ne dici di prevenire CSRF in questo modo?

Questo è probabilmente un cattivo meccanismo, poiché viola il principio di Kerckhoff . Se un utente malintenzionato sa come funziona la "crittografia", può semplicemente crittografare il proprio BLOB CSRF per un utente specifico e utilizzarlo in attacchi mirati.

CSRF sfrutta il fatto che il tuo browser invierà un cookie contenente un ID di sessione che ti autentica sul server, anche se la richiesta è generata da uno script automatico. Per proteggerti da questo, devi solo richiedere un token sconosciuto a un utente malintenzionato e che non viene automaticamente inviato dal browser senza istruzioni dirette. Il modo standard per farlo è generare un valore casuale, noto come token CSRF, e aggiungerlo ai parametri di una richiesta POST. Finché lo script di destinazione verifica il token CSRF in qualche modo, sei protetto.

Il modo più semplice per farlo è generare un token CSRF casuale all'avvio della sessione e memorizzarlo come variabile di sessione. Può quindi essere iniettato in moduli che richiedono la protezione CSRF e controllato dallo script di destinazione.

L'aggiunta di eventuali "extra" a questo schema, come la crittografia / timestamp è snakeoil - cioè non fornisce alcuna sicurezza reale e complica lo schema, il che si traduce in una superficie di attacco potenzialmente maggiore. Ricorda: non essere un Dave!

one of my colleges wants to generate the token by encrypting the current sign-in user's id concatenating a timestamps with a safely kept password. And then append the token into the form.

Va bene e un approccio comunemente usato dove le sessioni non sono disponibili. Ma usa un MAC standard per questo (es. HMAC-SHA256) invece del tuo hash concatenato single-layer.

Un'altra considerazione è la gestione del ciclo di vita delle chiavi: hai intenzione di cambiare il server segreto ogni tanto? Avete un meccanismo per fornire un cambio fluido quando fate (o quando ritirate il segreto dopo un compromesso)? O è OK rompere i vecchi token di tutti in quello scenario?

Sembra che tu stia utilizzando uno schema di valori firmati simile per il cookie auth. In tal caso, si dovrebbe considerare (se non lo si è già fatto) includendo un identificativo della password utente come parte del testo non crittografato / firmato, in modo che quando l'utente cambia la propria password invalida tutti i token precedentemente emessi. Questo potrebbe essere un numero di generazione, un cambio di data e ora o un deposito di riserva.

C'è anche l'implicazione che, poiché il dato che si sta cercando per la protezione XSRF è l'ID utente, non si è in grado di proteggere il modulo di login stesso. Considera cosa succederebbe se un utente malintenzionato usasse XSRF per indurre un utente ad accedere automaticamente a un account di scelta dell'hacker, magari senza che l'utente notasse a quale account sono collegati come; ciò costituisce potenzialmente una minaccia?

Un approccio che risolve questo se ne hai bisogno è aggiungere cookie auth per utenti non autenticati e includere un segreto nel cookie auth. Quindi includi / firma quel segreto nel token XSRF: effettivamente il token XSRF sta firmando il cookie auth.

Questo è un approccio valido nella protezione dagli attacchi CSRF. Alcuni vantaggi rispetto ai metodi tradizionali includono:

• Non è dipendente dalla sessione
• Non espone le vulnerabilità dei sottodomini come Double Submit

Si chiama Pattern token crittografato. Controlla questo link per una spiegazione completa e panoramica architettonica. Vedi anche la descrizione di OWASP .