Me pregunto si un ataque CSRF divulgará la información que se envía de vuelta en una solicitud GET.
Necesito enviar un número de seguro social al cliente unas cuantas veces, y NO es que nadie más pueda recibir. Los datos ya están protegidos por HTTPS, pero sé que eso no detendrá un ataque CSRF.
La solicitud en sí no cambiará nada en la aplicación, pero los datos no deben filtrarse.
¿Cómo puede ser explotado? ¿Y qué medidas puedo tomar para prevenirlo?
Un ataque CSRF significa que un sitio web engaña a un usuario para que realice una solicitud de página en otro sitio web que no deseaba realizar. Esto se puede usar para engañar al usuario para que realice una acción en ese sitio web que no pretendía realizar.
Podría, por ejemplo, pedirte que haga clic en este vínculo increíble (¡de verdad, es genial!) , y accidentalmente provocará que elimine su cuenta en example.com (solo un ejemplo: no existe tal script en example.com). Cuando tuviera más control sobre este sitio web, podría usar un script o un redireccionamiento HTTP, por lo que no sería necesaria la ingeniería social. Pero cualquier respuesta a esa acción sería enviada a usted, no a mí. Eso significa que cuando la acción no es destructiva y solo lee información sin cambiarla, un CSRF no tendría sentido. En el peor de los casos, el usuario se preguntará por qué se le redirige de repente al sitio web que muestra su número de seguridad social.
Pero hay una forma de que un sitio web obtenga información de un sitio web diferente en el contexto del usuario: xmlHttpRequest. Normalmente, las mismas políticas de origen aplican y evitan que xmlHttpRequests cruce los bordes del dominio. Pero esta restricción puede ser anulada por la configuración de Intercambio de recursos entre orígenes en su servidor web . Cuando activa accidentalmente CORS para el otro sitio web (o todos sitios web), pueden enviar solicitudes en el contexto de sus usuarios a su sitio web y leer la respuesta. Cuando desee saber cómo verificar o cambiar la configuración de CORS en su servidor web, consulte su documentación.
CSRF generalmente no sería una amenaza aquí, ya que los ataques CSRF son ataques de sesión que no involucran al atacante. Sin embargo, si el ataque CSRF implica cambiar las contraseñas de los usuarios, el atacante podría acceder a mucho más que el SS #. Además, si el ataque CSRF podría usarse en combinación con un ataque XSS, en algunos casos esto podría revelar mucha información confidencial.
De cualquier manera, las protecciones generales CSRF (cookies no enviadas o con doble envío), las protecciones XSS (filtrado de entrada y salida) y las redirecciones adecuadas, si corresponde, lo evitarían. El hecho de que sea una solicitud GET limita la exposición, pero de ninguna manera garantiza que sea segura.
CSRF no es posible, pero solía haber secuestro JSON para preocuparse acerca de. Sin embargo, esto no ha sido un problema durante mucho tiempo y ya no es posible en los navegadores modernos .
De 2 : -
Chrome 2.0.172.31 y Firefox 3.0.11 fueron vulnerables a esto.
Aquí es donde la matriz de JavaScript y los definidores de objetos se redefinieron en la página antes de que se realizara una solicitud JSON al dominio remoto. Cuando se devolvió el JSON, el código definido en los nuevos configuradores se ejecutaría y filtraría los datos a la página remota.
Echa un vistazo a esta publicación para obtener algunos consejos si quieres asegurar tu código para usarlo en navegadores antiguos. o navegadores raros que pueden ser vulnerables.
Lea otras preguntas en las etiquetas http session-management csrf