¿Debo darle al token de csrf un nombre descriptivo?

Llámelo así si lo desea; no afecta la seguridad de su sistema de ninguna manera.

Al final del día, no puedes protegerte de todo. Si se trata de ingeniería social, el estafador podría simplemente idear una razón para que el usuario les dé la contraseña de la cuenta directamente.

También hay otros ataques que son difíciles de defender cuando hay usuarios involucrados, como Self-XSS . Aquí es donde un estafador convence a un usuario de ingresar algún código JavaScript en las herramientas de desarrollo del navegador con la promesa de piratear la cuenta de otra persona.

Un mejor enfoque para estos dos problemas es educar a sus usuarios .

Debería usar tokens para evitar un spamming "rápido" de sus formularios y solicitudes en general. Pero, en realidad, el pirata informático puede ver la solicitud con toda la consulta y notar que hay un token utilizado. Una vez que lo consiguió, puede crear un bot de spam con el token aleatorio que usa tu formulario.

Una mejor manera de estar seguro sería usar, digamos 3 (o más) tokens y un valor de sesión con un número aleatorio entre la cantidad de tokens que usas. Por lo tanto, puede usar el valor de sesión como una selección aleatoria para el token y validarlo en cualquier lugar que desee. Por lo tanto, es impredecible porque los datos de $ _SESSION están ocultos en la interfaz.

Algo como:

// 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

Mejor busca otros problemas de seguridad, sí puede combatir los ataques SE, Pero, ¿por qué le darías DO_NOT_give_this_security_thingy_to_anybody_ever a un nombre de token csrf? haga que el token de csrf no sea reutilizable, resolverá el problema!