2009-11-23 15 views
19
  1. Requerir autenticación en GET y POST de parámetros, no sólo las cookies;impidiendo que CSRF en php

  2. Comprobando el encabezado HTTP Referer;

vio esta entrada en la wikipedia y se preguntaba cómo puedo aplicarlos

bien ... Estoy utilizando el marco Kohana PHP y tengo la instalación para determinar el encabezado de referencia, pero ¿qué es exactamente lo ¿Reviso el encabezado de referencia? la función de marco solo devuelve la URL de la referencia

y cómo validar los parámetros GET y POST? ¿contra que? información almacenada? tipo esperado?

Respuesta

39

Para evitar CSRF, querrá validar un token de un solo uso, POST'ed y asociado con la sesión actual. Algo como lo siguiente. . .

En la página en las solicitudes de los usuarios para eliminar un registro:

confirm.php

<?php 
session_start(); 
$token= md5(uniqid()); 
$_SESSION['delete_customer_token']= $token; 
session_write_close(); 
?> 
<html> 
<body> 
<form method="post" action="confirm_save.php"> 
<input type="hidden" name="token" value="<?php echo $token; ?>" /> 
Do you really want to delete? 
<input type="submit" value=" Yes " /> 
<input type="button" value=" No " onclick="history.go(-1);" /> 
</form> 
</body> 
</html> 

Luego, cuando llegue el momento de eliminar el registro:

confirm_save.php

<?php 
session_start(); 
$token = $_SESSION['delete_customer_token']; 
unset($_SESSION['delete_customer_token']); 
session_write_close(); 
if ($token && $_POST['token']==$token) { 
    // delete the record 
} else { 
    // log potential CSRF attack. 
} 
?> 

El token debe ser difícil de adivinar, único para cada solicitud de eliminación, aceptado solo a través de $ _POST y caducado después de unos minutos (el vencimiento no se muestra en este ejemplo).

+0

¿La expiración de la sesión no debería ser suficiente? Me refiero a no verificar la caducidad con una función personalizada. –

+0

Las sesiones no impiden CSRF @JavierConstanzo. A veces duran semanas o más.¿Qué sucede si abre un sitio web con un ataque CSRF mientras su sesión todavía está activa? –

+0

¿Por qué debería configurar su servidor @EdsonMedina para tener sesiones que duran semanas? Sé que las sesiones no son suficientes para prevenir CSRF, no estaba implicando eso. –

3

Con la comprobación de referencias, lo único que hace es asegurarse de que el referidor sea de su sitio/sistema. Si el referenciador no existe o es de un sitio extranjero, la verificación de referencia falla y es posible que no desee cumplir con cualquier solicitud que se realice.

En el pasado, los problemas con varias tecnologías y navegadores (flash..et al) permitían la falsificación de los encabezados de referencia. Es algo a considerar. Hay varios métodos que usan javascript para vincular a los recursos donde los datos de referencia no están presentes/pasados ​​en el encabezado de la solicitud.

Este comportamiento varía un poco entre los navegadores. Si usa javascript para enviar un formulario, generalmente está bien. Si usa algo como window.location, probablemente no espere que los datos de referencia estén presentes.

Un método popular para la prevención de CSRF es no utilizar cookies y pasar siempre el estado entre referencias ... Pasar un token de sesión en todos los enlaces a través de una aplicación.

+1

Muy cierto, el encabezado de HTTP Referer puede falsificarse fácilmente y no ofrece ninguna protección real contra CSRF. – leepowers

2

[Nota:] Kohana framework está en desuso, la nueva horquilla para Kohana PHP 7 es https://koseven.ga/ y no admite la funcionalidad CSRF de la clase de seguridad.

Puede usar la función de seguridad oficial koseven. Aquí hay un enlace al koseven security class.