Knoppia

Wiki de Informática y otras historias

Herramientas de usuario

Herramientas del sitio


app:inses

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Ambos lados, revisión anteriorRevisión previa
app:inses [2024/10/17 16:26] thejuanvisuapp:inses [2024/10/24 15:28] (actual) thejuanvisu
Línea 73: Línea 73:
 Un requisito para este tipo de ataque es que el usuario debe estar logueado. Otro requisito es que el atacante debe ser capaz de enviar al usuario una petición maliciosa. Esta vulnerabilidad se aprovecha de que las peticiones HTTP sean repetibles ya que los parámetros que se envían son siempre los mismos, no hay componentes aleatorios que varíen cada vez. Para paliar esto se establece un campo aleatorio en los formularios. Un requisito para este tipo de ataque es que el usuario debe estar logueado. Otro requisito es que el atacante debe ser capaz de enviar al usuario una petición maliciosa. Esta vulnerabilidad se aprovecha de que las peticiones HTTP sean repetibles ya que los parámetros que se envían son siempre los mismos, no hay componentes aleatorios que varíen cada vez. Para paliar esto se establece un campo aleatorio en los formularios.
  
-(Continua la semana que viene)+Para prevenir estos ataques se debe comprobar que la cabecera HTTP tenga ciertas cabeceras y añadir un token en las peticiones (CSRF Token) que se debe regenerar cada sesión, de forma que no sea repetible y que el atacante no pueda reproducir el formulario de forma sencilla. 
 +  * Analizar cabeceras Origin, Refer y Host para determinar la procedencia. El navegador no permite modificar estas cabeceras con javascript. 
 +  * El CRFS Token debe tener las siguientes características: 
 +      * Único por sesión 
 +      * Valor aleatorio de tamaño largo 
 +      * Generado por un algoritmo criptográfico. 
 +  * En las aplicaciones con estado el token se puede almacenar en la sesión. 
 +  * Las peticiones deben incluir este token como parámetro o en alguna cabecera. 
 +  * El servidor compara el token de la petición y el de la sesión de forma que si estos no coinciden se descarta la petición 
 +  * El token NO debe ir en la URL 
 +  * En algunas ocasiones no es viable almacenar el token de sesión, por lo que se envía una cookie doble (Double Submit Cookie) 
 +  * Las cookies con el atributo SameSite permiten especificar que no se envíe la cookie si la petición viene de un servidor diferente. 
 +  * Otra medida de seguridad podría ser el uso de doble autenticación. 
  
  
app/inses.txt · Última modificación: 2024/10/24 15:28 por thejuanvisu