Es una medida de seguridad, como lo indica la descripción en el código. El iframe sirve como mecanismo de protección contra los ataques de XSS a través de medidas propias de los exploradores contra estos mismos tipos de ataques al impedir el acceso de JavaScript a marcos e iframes cuando no se publican en el mismo dominio. No es realmente necesario escribir esta parte del HTML directamente en el documento, ya que también podría estar escrito por el mismo JavaScript que está manipulando sus contenidos, pero el desarrollador de esta solución probablemente quiso dejarlo claro a los futuros desarrolladores. que algunas secuencias de comandos externas están verificando el formulario de inicio de sesión antes de su publicación y que los mecanismos de prevención XSS de los navegadores se utilizan para lograr una mejor seguridad para el usuario final al iniciar sesión. Esto también está fuertemente implícito en la falta de una ID para el iframe, lo que haría que la referenciación sea mucho más fácil.
El desarrollador adjuntaría un elemento script de JavaScript a iframe DOM con un código que se vería así:
window.onload = function () {
var iframe = document.createElement('iframe');
iframe.width = "0px";
iframe.height = "0px";
iframe.style.visibility = "hidden";
iframe.id = "noXSSframe";
iframe.setAttribute("src", "about:blank");
document.getElementById("formID").appendChild(iframe);
iframe.addEventListener('load', function (e) {
var myElement = document.createElement('script');
myElement.setAttribute('src', '/content/test.js');
myElement.setAttribute('type', 'text/javascript');
iframe.contentDocument.body.appendChild(myElement);
}, false);
}
Esto es solo un ejemplo y no es necesariamente el mismo método que eligió su desarrollador, pero debería ser lo suficientemente bueno para propósitos de demostración.
Este archivo JavaScript externo que se acaba de adjuntar al iframe se escribirá de tal manera que se ejecute a través de un iframe, haciendo referencia al objeto del documento principal de manera que solo se permita un script ubicado en el mismo dominio. mientras que las inyecciones de XSS que reemplazan el script llamado por un script alojado fuera del dominio del documento principal claramente se les negará el acceso a los navegadores. La única forma de evitar que los navegadores apliquen la misma política de origen para XMLHttpRequests es adjuntando encabezados adicionales a la respuesta HTTP del servidor y permitiendo explícitamente recurso de origen cruzado compartir (CORS) . Sin embargo, esto no es algo que solo las inyecciones de XSS puedan manipular.
En resumen, es una forma elegante de asegurarse de que el JavaScript responsable de la manipulación, la verificación y, finalmente, la publicación de un formulario de inicio de sesión (preparación e inicio de una solicitud HTTP) se cargue desde un archivo alojado en el mismo dominio que el registro -En forma está encendido, previniendo efectivamente simples inyecciones de XSS. Al mismo tiempo, también evita que los sitios de phishing reutilicen este formulario de inicio de sesión y envíen solicitudes de inicio de sesión a otro dominio, si el script de iframe realiza alguna verificación adicional, adjuntando valores de respuesta únicos que se pueden verificar al final del servidor en los formularios. solicitud POST .