csrf_token - ¿Necesito un token CSRF para jQuery.ajax()?
csrf token laravel (3)
El riesgo de CSRF es que un sitio externo podría enviar datos al suyo y el navegador de los usuarios enviará automáticamente la cookie de autenticación junto con este.
Lo que necesita es una forma para la acción de recepción (que su método $.ajax() está enviando datos POST) para poder verificar que la solicitud proviene de otra página en su sitio, en lugar de un sitio externo.
Hay un par de formas de hacerlo, pero la forma recomendada es agregar un token a la solicitud que puede verificar y que los hackers no pueden acceder.
En su forma más simple:
- Al iniciar sesión, cree un token de cadena aleatorio largo y guárdelo contra el usuario.
- Agregue un parámetro a la solicitud
$.ajax()que incluye el token. - A petición, compruebe que el token coincida con el que ha guardado para el usuario.
- Si el token no coincide, tienes un truco CSRF.
El hacker no puede acceder a su base de datos y no puede leer realmente la página que ha enviado al usuario (a menos que reciba un ataque XSS, pero ese es otro problema) por lo que no puede falsificar el token.
Todo lo que importa con el token es que puedes predecirlo (y validarlo) y que el hacker no puede .
Por esta razón, es más fácil generar algo largo y aleatorio y almacenarlo en la base de datos, pero en su lugar podría crear algo cifrado. Sin embargo, no solo usaría el nombre de usuario MD5: si los atacantes de CSRF descubren cómo generar tus tokens, serás pirateado.
Otra forma es almacenar el token en una cookie (en lugar de en su base de datos), ya que los atacantes no pueden leer ni cambiar sus cookies, solo causan que se vuelvan a enviar. Entonces usted es el token en los datos HTTP POST coincide con el token en la cookie.
Puede hacer que estos sean mucho más sofisticados, por ejemplo, un token que cambia cada vez que se usa con éxito (evitando el reenvío) o un token específico para el usuario y la acción, pero ese es el patrón básico.
Así que tengo un método POST básico .ajax () para un archivo PHP.
¿Qué medidas de seguridad necesito?
Algunas publicaciones mencionaban el uso de un campo de entrada MD5 oculto que usted envía a través de AJAX y verifica en el archivo PHP. ¿Es este un método suficientemente bueno?
En términos de falsificación de solicitudes, no importa cómo el cliente envía la solicitud, importa cómo se recibió. Se aplican las mismas reglas de CSRF para una publicación de Ajax que cualquier otro tipo de publicación.
Recomiendo leer la hoja de trucos de prevención de CSRF . El uso de un token secreto por usuario es la forma más común de protección.
No se necesita ningún token, pero aún debe proteger las funciones que cambian de estado contra CSRF.
Una forma simple de hacerlo es agregar un encabezado que se envía con la solicitud AJAX. No se necesita ningún token aleatorio.
Esto funciona porque:
- Los formularios HTML no pueden tener encabezados personalizados agregados por un atacante.
- Los encabezados personalizados no pueden pasarse a través del dominio sin que CORS esté habilitado.
Por supuesto, el código del lado del servidor debe garantizar que el encabezado esté presente antes de ejecutar su acción.
Más información: ¿Cuál es el punto del encabezado X-Requerido-Con?