[07 de Julio de 2014 | No hay Comentarios ]
El Cross-site request forgery (CSRF) o falsificación de petición en sitios cruzados (también conocido como Session Riding) es un tipo de script malicioso de un sitio web en el que comandos no autorizados son transmitidos por un usuario en el cual el sitio web confía.
Oscar Lastera
El Cross-site request forgery (CSRF) o falsificación de petición en sitios cruzados (también conocido como Session Riding) es un tipo de script malicioso de un sitio web en el que comandos no autorizados son transmitidos por un usuario en el cual el sitio web confía. Esta vulnerabilidad es conocida también por otros nombres como XSRF, enlace hostil, ataque de un click, cabalgamiento de sesión, y ataque automático.
Se trata de una técnica prácticamente desconocida pero extremadamente peligrosa que permite aprovechar que tenemos abierta una sesión en el navegador con un sitio fiable (un banco, gmail, ...) para que desde el código HTML de una página que estemos visitando se cree una petición que podría tener la consecuencia de enviar una petición (legítima en apariencia porque procede de un navegador en el que mantenemos una sesión válida abierta) a la aplicación web del banco para que realice una operación sin que sea en ningún momento evidente.
Mecanismos de Defensa
Uso de un token :
Este es uno de los mecanismos más utilizados frecuentemente, el cual aporta un buen nivel de seguridad si se hace correctamente. Se basa en la generación y codificación de un número aleatorio (token) tras el login del usuario en la aplicación, que se almacena en la sesión del usuario. En cada formulario que se le presente al usuario se incluye un campo oculto en el que se escribe este token. A la recepción del formulario en el servidor se comprueba que el token se haya recibido y coincida con el almacenado para el usuario. Si el token no coincide se aborta la acción del formulario.
Con el fin de evitar que el token pueda ser fácilmente visible en la barra de direcciones del navegador o que llegue a otras páginas vía la cabecera HTTP_REFERER, es aconsejable enviar siempre el token mediante POST. En aplicaciones en las que se utilice una conexión automática si el usuario ya se ha autenticado alguna vez anterior, también es conveniente hacer que el valor de token expire, bien de forma independiente o con la sesión, con el objetivo de que si alguien obtiene el token éste caduque pasado un tiempo.
Encontre una clase facil de implantar y de seguridad bastante aceptable. os dejo la cabecesra de la clase :
/**
* NoCSRF, an anti CSRF token generation/checking class.
*
* Licensed under the MIT license <http://www.opensource.org/licenses/mit-license.php>
*
* @author Thibaut Despoulain <http://bkcore.com>
* @version 1.0
*/