Algunos de ustedes pueden estar familiarizados con este ataque llamado Self Contained XSS. Recientemente me topé con el artículo este al respecto. Entonces, ¿qué tan grave puede ser este tipo de ataque, aunque no tenga acceso a los elementos DOM actuales? ¿Alguien ha visto esto en la naturaleza?
¿Esto afecta también a los navegadores móviles?
Otro enlace útil .
XSS autocontenido, es tan malo como XSS en sí mismo. Es solo una de las formas de suministrar la carga útil. Los enlaces en su pregunta describen dos vectores diferentes:
<iframe> con src de data:text/html,<html><script>alert(/xss/)</script></html> , pero hay muchas, muchas otras formas de usar las URL de datos para XSS. Puede ver algunos de ellos buscando data: en hoja de datos de seguridad de HTML5
¿Se ha utilizado en la naturaleza? Sí, por ejemplo, lo utilicé para explotar una Vulnerabilidad de Piwik XSS
with(location)with(hash)eval(substring(1)) pero hay muchos vectores similares. Entonces, para resumir, el XSS autónomo no es otro tipo de XSS (como el XSS almacenado o el XSS basado en DOM), son solo formas de cómo se ve la carga útil. Realmente no puedes decir que es más peligroso que el propio XSS.
Este es en realidad un viejo problema. Puede codificar cualquier tipo de medio utilizando el URI data . Es bastante común usarlo para incrustar imágenes en un solo archivo de marcado.
<img src="data:image/png;base64,ABCdefghIjKlmNoPqrSTuvwxyZ01d" />
La razón por la que esto es peligroso es que cualquier ataque XSS podría permitir que un atacante incrustara un URI data . Si el usuario lo descarga, podría estar accediendo a cualquier tipo de archivo. Lo que es peor, es una forma de incrustar datos que pueden explotar otras vulnerabilidades en navegadores o componentes de representación subyacentes, desde un sitio en el que el usuario confía.
Por ejemplo, imagina que Bob's Crazy Discount Spoons tuvo un ataque XSS en el que se puede manipular el src de una imagen:
http://bobscrazydiscountspoons.com/foo/bar.php?xss=data:image/png;base64,ABCdefghIjKlmNoPqrSTuvwxyZ01d
El usuario ahora recibe una carga útil desagradable que explota una vulnerabilidad en el procesador PNG de su navegador, en lugar de las locas cucharas de descuento que deseaba.
Por supuesto, esto no se limita a las imágenes. En cualquier lugar donde pueda inyectar en la fuente o enlace de un objeto, se puede utilizar. Lo mismo se aplica para poder inyectar este tipo de datos en ataques de inyección de código HTML completos.
Entonces, ¿qué tan malo puede ser este tipo de ataque, a pesar de que no tiene acceso a los elementos DOM actuales?
Es peor que los ejemplos bastante limitados en el artículo vinculado: en Firefox y Opera, data: URIs do operan en el mismo contexto de seguridad que el documento que los incluye, y por lo tanto puede acceder a elementos DOM en su dominio. Esto no ocurre en Chrome / Safari, o IE9 (que deliberadamente solo tiene soporte parcial para data: URIs).
En el caso de que se puedan incluir documentos HTML, esto conlleva los mismos riesgos que el XSS convencional. Principalmente son marcos y enlaces, pero son posibles otros ataques (*).
ejemplo: enlace : crea un enlace y un iframe, inyectando el documento HTML que escribe en los datos: URL en ambos. El código en el documento vinculado / enmarcado recoge el contexto de seguridad de jsbin.com, lo que le permite alertar sobre el código fuente de la página de índice de jsbin.
Por consiguiente, debe considerar que data: URI es tan riesgoso como javascript: URI, y rechazarlos en todos los sitios donde su aplicación web permita que se envíen URI. (Realmente, lo mejor es incluir en la lista blanca los esquemas de URI para mantener una selección limitada, como http / https ).
(*: por ejemplo: ponga un URI de data:text/html... enviado por el atacante en un <img src> y la imagen no funcionará. Pero si el usuario puede ser engañado en la imagen de clic con el botón derecho, habría cargue el recurso como HTML, resultando en XSS.)
Lea otras preguntas en las etiquetas web-application attacks xss javascript