Pruebas CSRF de un punto final de API utilizando solicitudes GET

Navega tus respuestas
2

Tengo un punto final de api que devuelve un nuevo token de api en JSON al usuario si ha iniciado sesión en mi sitio web y solo se utilizan sus cookies de sesión para autenticarse.

Estoy tratando de escribir un fragmento de código que se carga automáticamente en un dominio diferente que envía una solicitud GET a ese punto final, usando las cookies de esa persona para ver si puedo buscar maliciosamente su nueva ficha api. Solo estoy comprobando si mi punto final es seguro o si es posible. Solo deseo que las solicitudes registradas desde el mismo dominio puedan llegar a ese punto final. No estoy seguro de si esto se considera realmente CSRF ya que no hay cambio de estado. Existe una política de CORS, por lo que no estoy seguro de si eso me impide hacerlo. Y el barniz es la parte delantera con X-XSS-Protection: 1 habilitado.

Lo que he intentado, simplemente tener una página de dominio diferente carga el punto final. Con un usuario registrado en otra pestaña. Esto devuelve un 200, con las cookies esperadas del usuario que inició sesión, pero no la respuesta JSON. 

<img src="https://mydomain/endpoint"width="0" height="0" border="0">

Lo siguiente devuelve un 200 con las cookies correctas del usuario registrado, pero no hay respuesta json. Creo que esto no está devolviendo datos debido a la misma política de origen en el navegador. Corrígeme si me equivoco. 

document.write('<img src="https://mydomain/endpoint?cookie='+document.cookie+'" />')

Tanto XMLHttpRequest como JQuery para realizar una solicitud GET al punto final objetivo, nuevamente desde un dominio diferente y un usuario que inició sesión en una pestaña diferente. Devuelve un 401 no autorizado y sin cookies. Tal vez haya algún jquery adicional que necesite capturar y enviar cookies con la solicitud. 

$.get('https://mydomain/endpoint', function(responseText) {
alert(responseText);});

Además de copiar la solicitud de curl desde la consola de desarrolladores de Chrome de una solicitud web exitosa al punto final de la API. Sorprendentemente, curl no devuelve el token nuevo incluso con los parámetros esperados & galletas. Quizás también por las mismas políticas de origen.

Otras ideas, ¿es esto posible con lo que he descrito?

    
pregunta mjmj 05.03.2018 - 19:13
fuente

2 respuestas

2

Como comenzó a mencionar, CSRF solo es realmente útil para acciones que cambian de estado, por lo que este no es realmente un ejemplo de CSRF.

De OWASP :

  

La falsificación de solicitudes entre sitios (CSRF) es un ataque que obliga a un usuario final a ejecutar acciones no deseadas en una aplicación web en la que están autenticados actualmente. Los ataques CSRF se dirigen específicamente a las solicitudes de cambio de estado, no al robo de datos, ya que el atacante no tiene forma de ver la respuesta a la solicitud falsificada.

Además, la razón por la que no puede ver la respuesta probablemente se deba al Intercambio de recursos entre orígenes (CORS).

documentos web de MDN indica:

  

Por razones de seguridad, los navegadores restringen las solicitudes HTTP de origen cruzado   iniciado desde dentro de scripts. Por ejemplo, XMLHttpRequest y la   Fetch API sigue la política del mismo origen. Esto significa que una web   La aplicación que utiliza esas API solo puede solicitar recursos HTTP desde el   mismo dominio desde el que se cargó la aplicación a menos que los encabezados CORS estén   utilizado.

Entonces, mientras que los recursos remotos son de hecho disponibles, el navegador no permite que JavaScript en sus páginas de prueba vea las respuestas. Tenga en cuenta que ese es el comportamiento predeterminado, a menos que haya hecho un gran esfuerzo para establecer los encabezados correctos en el servidor.

    
respondido por el multithr3at3d 05.03.2018 - 19:19
fuente
2

Mientras CORS esté configurado correctamente, no es posible extraer información de otro dominio a través de JavaScript.

También debe verificar que sus puntos finales JSON devuelven un objeto, y no una matriz, para proteger contra / a>, una antigua vulnerabilidad que afecta a los navegadores antiguos.

    
respondido por el Benoit Esnard 05.03.2018 - 19:20
fuente

Lea otras preguntas en las etiquetas

Cuándo y por qué enviar una notificación por correo electrónico de restablecimiento de contraseña ¿Cuando se requiere cerrar sesión en un sitio web, se destruye la sesión?