Sé que una etiqueta de formulario es propensa a CSRF que no usa ningún token (o cualquier otro mecanismo de desafío-respuesta) pero me preguntaba cómo se puede usar un iFrame para causar un ataque XSRF y ¿cuáles serían las técnicas de mitigación? A continuación se muestra el ejemplo del código:
document.write('<IFRAME SRC="https://somedomain/abcde;src=;type=;cat=;ord=;num='+ a + '?" WIDTH=1 HEIGHT=1 FRAMEBORDER=0></IFRAME>');
El ejemplo de código que proporcionó es una vulnerabilidad de scripts de sitios , ya que permite la ejecución de JavaScript arbitrario , asumiendo que "a" no es de confianza:
a = "\"); evil(); document.write(\""
Un sitio malicioso puede usar un IFrame para explotar un sitio vulnerable a través de CSRF :
En un ataque CSRF típico, el navegador es engañado por un sitio malicioso para enviar una solicitud a un sitio vulnerable. El navegador incluirá las cookies para ese sitio, por lo que la solicitud se autentica desde el punto de vista del sitio vulnerable.
Si bien hay varias formas de activar la solicitud GET, las solicitudes POST entre sitios generalmente se crean al enviar un formulario. Si bien se puede usar JavaScript para activar el envío automáticamente, no se puede usar para ocultar la página de resultados . Entonces, en un simple ataque CSRF basado en POST, se advertirá al usuario después del hecho.
Entonces, el truco es colocar el formulario de envío automático malintencionado en un IFrame invisible . Por lo tanto, el usuario no verá la página web que muestra el resultado del envío.
Un ataque relacionado es click-jacking : el sitio vulnerable (por ejemplo, el de Facebook). botón) se carga en un Iframe transparente y se usa JavaScript para desplazarlo a la ubicación apropiada y mantenerlo posicionado en el cursor del mouse. Si el usuario se cansa de hacer clic en cualquier parte del sitio malicioso, en su lugar, hará clic en el Iframe transparente.
Un iframe no puede introducir una falsificación de solicitud entre sitios o una vulnerabilidad de secuencias de comandos entre sitios. Un iframe no puede influir en una aplicación de esta manera debido a las Reglas de herencia de origen para los iframes .
Losiframes son utilizados por el atacante en un ataque de compensación de IU . También debes leer la hoja de trucos de prevención de CSRF . Especialmente la parte sobre cómo se puede utilizar XSS para socavar los sistemas de protección CSRF.
Si la aplicación vulnerable CSRF se permite incrustarse en un Iframe, entonces sí. ¿Cómo ayuda al atacante?
Los iframes pueden hacerse invisibles estableciendo el tamaño a cero. Por lo tanto, en comparación con el csrf normal donde la víctima puede tener una idea de algo sospechoso, en caso de iframe invisible, no verá nada.
El atacante enviará el formulario en nombre de la víctima donde se incrustará el formulario dentro de iframe. Esto es genial.
De hecho, hay un truco más que puede usar un atacante si la aplicación usa un token para evitar el CSRF, pero aún así se deja enmarcar.
Usando el método de captcha falso, puede engañar al usuario para que envíe el token usando ingeniería social y javascript. Tenga en cuenta que esto funciona solo en Firefox, ¡¡sorpresa !!
Lea otras preguntas en las etiquetas web-application source-code penetration-test attack-prevention csrf