Métodos CSRF: img vs iframe vs form / javascript

2

Tengo una pregunta sobre los métodos para ejecutar CSRF. Realicé la lección del paso rápido de solicitud de CSRF en WebGoat (Lecciones - > Creación de secuencias de comandos entre sitios - > By-pass de solicitud CSRF). La lección requiere que elabore un mensaje de correo electrónico que envíe dos solicitudes maliciosas a una aplicación web en la que el destinatario haya iniciado sesión. La primera solicitud establece una cantidad de transferencia de dinero. La segunda es una solicitud de confirmación que se envía cuando el usuario hace clic en "confirmar" en una página de confirmación.

Resolví la tarea utilizando el código JavaScript que envía las solicitudes como solicitudes HTTP Post. Supongo que otra opción sería utilizar formularios y JavaScript para enviar los formularios automáticamente.

Mi pregunta es ¿por qué la mayoría de las personas parece resolver la lección utilizando etiquetas img o iframes con src configurado en la URL de destino con los parámetros necesarios? esperaría que se realice una transferencia de dinero usando Solicitudes HTTP POST, no GET. ¿Hay algún aspecto que haría que el uso de un código JavaScript o un método inválido o problemático para CSRF? ¿Hay alguna diferencia práctica en comparación con las tareas antes mencionadas? Creo que la autorización no es así porque puede recibir las cookies enviadas a través de JavaScript y al enviar un formulario.

    
pregunta hubbabubba 17.12.2018 - 10:16
fuente

2 respuestas

1

Puedo pensar en dos razones principales por las que uno podría preferir el uso de img y iframe sobre una prueba de concepto de JavaScript para el escenario que describió anteriormente.

  1. Existe una mentalidad común que veo entre los miembros de la industria de la seguridad que la simplicidad es clave a la hora de construir pruebas de conceptos. A menudo se encontrará con personas que intentan construir las cargas útiles más cortas para explotar problemas específicos. Según su experiencia personal, su prueba de conceptos tiende a ser más fácil de entender y compartir con otros investigadores de seguridad (aunque no siempre es así, como vemos con los políglotas XSS [1] ). Además de eso, también es divertido intentar reducir su carga útil (consulte " Code golf ").
  2. Cuando se trata de explotar el problema, un adversario probablemente querrá cubrir la mayor cantidad de casos posibles. Algunos usuarios deshabilitan JavaScript en su navegador, lo que haría que su vulnerabilidad sea inofensiva. Un exploit no basado en JS resolvería este problema potencial.
respondido por el EdOverflow 17.12.2018 - 15:06
fuente
1

Las razones por las que las personas usan estas etiquetas en lugar de usar JavaScript, IMO, son:
- Ejemplos de artículos / publicaciones anteriores
- Aplicaciones que permiten a los usuarios publicar imágenes / iframes (BBCode, Markdown, etc.)
- HTML puro y amp; facilidad de demostración

Los ejemplos anteriores usaban etiquetas img o iframe porque JavaScript XHR no estaba disponible y probablemente no todos los navegadores permitirían ejecutar scripts. Y debido a las diferencias de implementación en los navegadores, los scripts podrían haberse roto fácilmente.
En segundo lugar, no es raro encontrar aplicaciones que permitan a los usuarios publicar imágenes a través de Markdown o etiquetas img HTML. Sin embargo, no permiten ningún fragmento de JavaScript o manejadores de eventos. Estos ya se han utilizado para dirigirse a audiencias más grandes en el pasado.
En tercer lugar, no requiere habilitar JavaScript ni ser bloqueado por NoScript o similar. Es corto y fácil de demostrar el ataque.

Estos son solo mis razonamientos. La verdadera razón puede diferir y puede entrar en conflicto con la mía. Apreciaría cualquier corrección.

    
respondido por el 1lastBr3ath 18.12.2018 - 19:49
fuente

Lea otras preguntas en las etiquetas