¿Cómo un token CSRF previene un ataque, y cómo puedo usarlo / evitarlo de manera segura para mi API JSON?

21

Estoy tratando de hacer que una aplicación iOS se comunique con un sitio web de Ruby on Rails usando JSON. Al intentar publicar un inicio de sesión para crear una sesión de usuario, descubrí que faltaba un token CSRF. No tenía ni idea de qué era eso, así que empecé a buscarlo y encontré algunas soluciones que dicen eliminar la protección CSRF si el formato de la llamada es 'application / json'. ¿Pero eso suena así que deja al sitio web vulnerable?

Surgieron algunos resultados acerca de los formularios JS que tenían el mismo problema. Las respuestas fueron para agregar en el token CSRF. La cual, luego de la inspección, también parece estar en la etiqueta de contenido meta en los encabezados de página.

Así que esto me deja en confusión, aquí están mis preguntas:

  • ¿Cómo ayuda el token a proteger algo si puede leerse en una llamada anterior a la llamada atacante? ¿Puede un sitio malintencionado no simplemente realizar una solicitud, analizar el mensaje recibido y enviar otra solicitud con el token?
  • ¿Sería seguro deshabilitar la comprobación de token en la acción de inicio de sesión de inicio de sesión y enviarla de vuelta junto con la respuesta correcta? Si no, ¿alguna sugerencia mejor?
pregunta Dan2552 22.12.2012 - 22:43
fuente

1 respuesta

21

Un resumen de cómo funcionan los ataques CSRF es el siguiente:

  1. Usted, el buen usuario, mientras está conectado a un sitio web A, visita la página B de otro sitio.
  2. Esa página hace un GET (puede ser un POST, un poco más complejo de configurar arriba) a una página X en el sitio A (en la que está conectado), por ejemplo, . Su navegador lo obliga a usar su sesión / cookie ya autenticada
  3. La página X por diseño causa un cambio en el estado de su cuenta - Los ejemplos clásicos son "transferir X dólares a B" (menos realistas) o "establecer la línea de estado del usuario en PWNED" (más realista)

Hay varias formas en que se puede implementar un token CSRF, pero la idea es que una simple solicitud GET para una URL X que cambia de estado no funcionará a menos que se incluya una información adicional cambiante (el token), por ejemplo. tiene que ser "X? token = 123123213". Dado que el token cambia con bastante frecuencia, el paso 2 anterior no funcionará. El posible atacante no conoce el token actual.

Tu pregunta 1: el atacante no ve el contenido de la página X, solo te obliga a visitarlo.

Su pregunta 2: dado que se trata de acciones cuando ya ha iniciado sesión, es más o menos correcto no usar la protección CSRF en la página de inicio de sesión. Sin embargo, existe la posibilidad de que te vean obligado a iniciar sesión como otra persona y no lo note.

enlace

Una clase más general de problemas es enlace

    
respondido por el Vitaly Osipov 23.12.2012 - 02:13
fuente

Lea otras preguntas en las etiquetas