dovrei assegnare al token csrf un nome descrittivo?

Chiamalo così, se vuoi - non influisce in alcun modo sulla sicurezza del tuo sistema.

Alla fine della giornata, non puoi proteggere contro tutto. Se l'ingegneria sociale è coinvolta, il truffatore potrebbe semplicemente escogitare un motivo per l'utente di fornire loro la password dell'account direttamente.

Ci sono anche altri attacchi difficili da difendere contro il coinvolgimento degli utenti, come Self-XSS . È qui che un truffatore convince un utente a inserire un codice JavaScript negli strumenti di sviluppo del browser con la promessa di hackerare l'account di qualcun altro.

Un approccio migliore a entrambi questi problemi è educare i tuoi utenti .

Dovresti usare i token per prevenire alcuni "rapidi" spamming dei tuoi moduli e richieste in generale. Ma in realtà l'hacker può vedere la richiesta con l'intera query e notare che c'è un token utilizzato. Una volta ottenuto, può creare un bot antispam utilizzando il token casuale utilizzato dal modulo.

Un modo migliore per essere sicuri sarebbe utilizzare, diciamo 3 (o più) token e un valore di sessione con un numero casuale tra la quantità di token che usi. Quindi puoi usare il valore della sessione come scelta casuale per il token e convalidarlo ovunque tu voglia. Quindi è imprevedibile perché i dati $ _SESSION sono nascosti nel frontend.

Qualcosa come:

// Setting tokens
$_SESSION['token_1'] = "ocdja45d6"; // Any random value
$_SESSION['token_2'] = "62d5sas9f";
$_SESSION['token_3'] = "d8o9fhd5ds";
$_SESSION['random_token'] = mt_rand(1, 3);

// Getting Token
$randToken = 'token_' . $_SESSION['random_token'];
$token = $_SESSION[$randToken];

// Validating Token
if($token == $postTokenFromHackerOrUser)
{
    // Is okay or not?
}

HTH

Cerca altri problemi di sicurezza, sì, può combattere gli attacchi SE, Ma perché dovresti dare DO_NOT_give_this_security_thingy_to_anybody_ever a un nome csrf-token? rendere il token csrf non riutilizzabile, risolverà il problema!