¿Cuál es la forma correcta de proteger la interfaz REST del robo de sesiones?

Question

¿Cuál es la forma correcta de proteger la interfaz REST del robo de sesiones?

#1 de user52472 (1 votos)

1

Supongamos que el atacante pudo inyectar JavaScript en el sitio web. Obviamente, puede hacer cualquier solicitud HTTP para back-end imitando las acciones del usuario, a menos que exista alguna confirmación, como el código SMS, que requiera la interacción directa del usuario (incluso en este caso, el JavaScript malicioso podría engañar al usuario). Entonces, supongo, este vector de ataque no podría ser defendido razonablemente. Pero si el atacante roba la sesión, puede hacerse pasar por el usuario y hacer casi cualquier cosa. Así que estoy pensando en la defensa de este vector. Claro, el servidor podría verificar la dirección IP, etc., pero no siempre es posible.

Lo primero: almacenar la sesión en una cookie solo de HTTP. JavaScript no puede robarlo. Hasta ahora tan bueno. Pero hay otra debilidad: el sitio web de terceros puede crear una etiqueta de formulario con la acción de mi servidor y enviar este formulario con la cookie del usuario. Uno podría usar tokens CSRF, pero nuevamente deberían estar disponibles para JavaScript, podrían ser robados si JavaScript está comprometido, deben mantenerse en el servidor web, lo que perjudica la escalabilidad, etc. Estoy pensando en usar el método PUT para cada acción REST (bueno, obviamente no será un REST adecuado, llamémoslo API HTTP). No hay forma de engañar al usuario para que emita una solicitud PUT desde el sitio web de terceros y la cookie solo de HTTP evitará el robo del valor de la cookie.

No estoy viendo este uso, ¿así que supongo que me estoy perdiendo algo y debería haber una forma más sencilla de proteger los puntos finales?

http rest

pregunta vbezhenar 27.09.2017 - 16:25

fuente

1 respuesta

Lea otras preguntas en las etiquetas http rest

¿Cómo bloquear el acceso desde una sola computadora, aparte de bloquear la IP? ¿Es posible escribir un valor mayor a 64 bits usando un ataque de cadena de formato (% n)?

score 1 · Answer 1

Creo que puede estar malinterpretando CSRF como un vector de amenaza. Un ataque CSRF es uno donde el atacante no tiene acceso al DOM y puede forzar al navegador del usuario a enviar una solicitud que incluya el token de autenticación del usuario. XSS es donde el atacante puede manipular el DOM. Si el atacante puede manipular el DOM, puede forzar al usuario a enviar cualquier solicitud, e incluirá los valores de cookie HTTPOnly y cualquier token anti-CSRF. Cualquier mitigación de CSRF implementada se puede omitir si un atacante puede controlar el DOM (XSS).

Dado esto, la mejor implementación incluiría tanto un token de autenticación HTTPOnly como un token anti-CSRF que sea accesible a JavaScript.

Además, se pueden implementar tokens anti-CSRF que no necesitan ser mantenidos en el lado del servidor utilizando cookies HttpOnly. Usted incluye un token generado aleatoriamente en una cookie HTTPOnly, e incluye el mismo token de una manera accesible al DOM. Cuando el cliente devuelva la solicitud, incluya el token anti-CSRF como encabezado (o mediante un método similar). Luego, en el servidor, debe validar que tanto el token de HTTPOnly como los tokens del encabezado coincidan. Un ataque CSRF enviará el token de HTTPOnly, pero no puede enviar el token de encabezado correspondiente. Un ataque XSS aún podrá evitarlo, pero como dijimos anteriormente, las mitigaciones anti-CSRF no funcionarán si el atacante controla el DOM.