Token anti-XSS, así me quedó. [Mini-aporte]

  • Autor Autor xcodex
  • Fecha de inicio Fecha de inicio
X

xcodex

Muy buenas!, estuve viendo una manera de realizar un token para protegerme de ataques XSS.

En un principio lo tenía de esta manera:
Genero un token:
PHP:
<?php
    session_start();
    session_regenerate_id();
    $bin = bin2hex(random_bytes(32));
    $unhash = hash('sha512', $session_id = session_id());
    $hora = hash('sha512', date ("d-m-Y"));
    $_SESSION['token'] = $unhash.$sid.$hora;
?>

En el formulario:
PHP:
<input type="hidden" name="code" value="<?php echo $_SESSION['token']; ?>">

Y en el proceso de validación:
PHP:
session_start();
session_regenerate_id();
if(hash_equals($_SESSION['token'],$_POST['code'])){
    //Resto del código.
}

Hasta aquí todo funcionando perfectamente, pero me preguntaba si por algún método podrían utilizar lo que está en el campo de tipo "hidden" (con clic derecho -> inspeccionar elemento).

Entonces en el proceso de validación le agregué lo siguiente:
PHP:
session_start();
session_regenerate_id();

$hashnuevo1 = ('sha512', mt_rand(1,9999);
$_SESSION['token'] = $_SESSION['token'].$hashnuevo1 ;
$_POST['code'] = $_POST['code'].$hashnuevo1;

if(hash_equals($_SESSION['token'],$_POST['code'])){
    //Resto del código.
}


¿Qué les parece?, seguramente se le puede agregar mas seguridad pero para un nivel novato puede funcionar bien.
 
Primero que nada, eso no protege de XSS, ya que XSS es una vulnerabilidad de inyección de código a causa de filtrar mal las variables.

Por lo que veo en el código lo estás para intentar detener XSS por POST, lo cual es raro, ya que una inyección por POST no se podría hacer de manera automática mediante la url, sino aprovechando algún otro bug o lo sencillo: El atacante convence al usuario de poner los datos en el formulario, probablemente ofuscándolos un poco para que crean que es un handicap o un error con el que el usuario obtendrá algo aprovechándolo (tu método aquí no es efectivo).

Alguno quizá pensará "Pero puedes poner un formulario POST en tu web y cuando se envíe que se mande a la web atacada"... Eso no funciona gracias a la política de mismo origen (Explicación en wikipedia).

La mejor protección contra XSS es siempre hacer lo mismo en otros casos: Solo permitir solo lo necesario y si entre lo necesario hay combinaciones conflictivas, usar filtros para detectarlo y eliminarlo.

kj
 
..ya que una inyección por POST no se podría hacer de manera automática mediante la url, sino aprovechando algún otro bug..

Entonces sirve para prevenirse de algún otro bug, no es tan innecesario entonces. 😛
 
No dije eso, ese otro bug quizá sea uno redundante y si es capaz de rellenar tu formulario igual debería ser capaz de hacerlo con el campo oculto "token" y puesto que el token no es uno que expire ni nada similar, con que coloque siempre el mismo debería bastar.

kj
 
No dije eso, ese otro bug quizá sea uno redundante y si es capaz de rellenar tu formulario igual debería ser capaz de hacerlo con el campo oculto "token" y puesto que el token no es uno que expire ni nada similar, con que coloque siempre el mismo debería bastar.

kj

Justamente es por eso que cambia el token en la validación. 🙂

- - - Actualizado - - -

Aaaaaaaaaaahhh ahora entendí jajaja, me disculpo. Había entendido mal tu explicación. @kj2
 
Última edición por un moderador:
Justamente es por eso que cambia el token en la validación. 🙂

El session no solo PHP lo puede escribir.

En mi caso con "otro bug" estoy imaginando algo como lo que se solía hacer antes con Flash para hacer CSRF, fue justamente para evitar este ataque que se comenzaron a usar estos tokens, pero para que el token funcione no debe poder controlarse totalmente del lado del usuario como en tu código (wordpress usa estos tokens, por ejemplo).

kj
 
El session no solo PHP lo puede escribir.

En mi caso con "otro bug" estoy imaginando algo como lo que se solía hacer antes con Flash para hacer CSRF, fue justamente para evitar este ataque que se comenzaron a usar estos tokens, pero para que el token funcione no debe poder controlarse totalmente del lado del usuario como en tu código (wordpress usa estos tokens, por ejemplo).

kj

Te había entendido mal, me disculpo.
Ya está entendido. :-D
 
Atrás
Arriba