CSRF con una API CORS JSON [duplicado]

Question

CSRF con una API CORS JSON [duplicado]

#1 de David (1 votos)
#2 de Anders (1 votos)

1

Tenemos api.example.com que se comunica con app.example.com, una aplicación nativa de Android y una aplicación de iOS. Queremos permitir que otros terceros también se comuniquen con la API si así lo desean, y como tal tenemos un conjunto de encabezados Access-Control-Allow-Origin: * .

Tenemos algunas rutas API que no requieren autenticación previa, como /reset-password y /login .

Todas las demás rutas API requieren un token de autenticación agregado, por ejemplo, /important-action?authtoken=abc123 . No acepta cookies en los encabezados o el cuerpo de las solicitudes. app.example.com guarda el token de autenticación en una cookie para preservar la sesión.

Lo que me cuesta entender es cómo evil.com puede explotar esta configuración. ¿Alguien puede dar algunos ejemplos de cómo podría funcionar un ataque o dejar de preocuparme y avisarme que CSRF no es un riesgo aplicable?

He leído otras respuestas que se refieren al "uso de cookies" pero no aclaran qué significa exactamente "usar". En nuestro caso, almacenamos el identificador en una cookie y lo agregamos a la URL de solicitud. La API ignora las cookies enviadas en el encabezado de la solicitud.

web-application cookies csrf api cors

pregunta Merlin Mason 15.01.2018 - 15:11

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application cookies csrf api cors

Desbordamiento de búfer debido a strlen, strcpy, strcat ¿Cómo sabe un módulo de sandbox la diferencia entre un código confiable y otro no confiable?

score 1 · Answer 1

La falsificación de solicitudes entre sitios requiere que el atacante pueda predecir la solicitud que se realizará. Asumiendo que los valores de autenticación son difíciles de predecir (es decir, valores aleatorios grandes, valores hash, etc.), entonces sería difícil para un atacante falsificar la solicitud.

Tenga en cuenta que si establece Access-Control-Allow-Origin: * , debe asegurarse de que los puntos finales no reflejen tokens válidos, o un atacante podría leerlos desde allí.

score 1 · Answer 2

Hay dos caminos posibles que un atacante tiene que explorar aquí:

¿Se puede hacer algo con las rutas que no requieren autenticación?
¿Puedo obtener de alguna manera el token?

Veamos el # 1, y los dos caminos. Si la ruta /reset-password simplemente envía un correo electrónico al propietario de la cuenta, no sirve de mucho.

El otro, /login , es más problemático. Si también configura Access-Control-Allow-Credentials: true evil.com podría "forzar" un inicio de sesión (al establecer el conjunto de cookies del token). Esto lo abre a inicio de sesión CSRF , que puede ser cualquier cosa, desde una gran cosa hasta una muy mala, según su aplicación. . Si no establece ese encabezado, las cookies en la respuesta se descartarán y usted estará bien.

En cuanto al # 2, depende de si ese token está disponible en otro lugar que no sea la cookie. Al remitente de solicitudes de origen cruzado nunca se le permite leer cookies, por lo que no puede leer el token desde allí. Pero tal vez se incluye en otro lugar? Quizás la respuesta contenga alguna URL con el authtoken param en ella?

No es que si la cookie se usó como autenticación cuando se envió desde el cliente, esta sería una historia diferente. Entonces podrías tener un gran problema aquí.

Aparte de CSRF, no se recomienda poner secretos en la URL. Después de todo, las URL terminan en todo tipo de registros, sin mencionar el historial del navegador. Si no hay razón para no hacerlo, simplemente pondría el token en un encabezado. El encabezado en realidad también ayudaría a proteger contra CSRF, ya que evil.com no podría establecerlo.