2.1 CVE-2012-1004
Varias vulnerabilidades de cross-site scripting (XSS) en UI / Register.pm en Foswiki antes de 1.1.5 permiten a los usuarios autenticados remotos con privilegios de CAMBIO inyectar secuencias de comandos web arbitrarias o HTML a través del (1) texto, (2) Nombre, (3) Apellido, (4) Nombre de la organización, (5) Url de la organización, (6) Profesión, (7) País, (8) Estado, (9) Dirección, (10) Ubicación, (11) Teléfono, (12) VoIP, (13) InstantMessagingIM, (14) Correo electrónico, (15) Página de inicio o (16) Parámetro de comentario. NOTA: algunos de estos detalles se obtienen de información de terceros.
https://nvd.nist.gov/vuln/detail/CVE-2012-1004
Categorías
CWE-79 : Neutralización inadecuada de la entrada durante la generación de la página web ('Cross-site Scripting')
El software no neutraliza o neutraliza incorrectamente la entrada controlable por el usuario antes de colocarla en la salida que se utiliza como página web que se sirve a otros usuarios. "XSS" es una abreviatura común de Cross-Site Scripting. "Inyección HTML" se utiliza como sinónimo de XSS almacenado (Tipo 2). En los primeros años tras el descubrimiento inicial del XSS, "CSS" era un acrónimo comúnmente utilizado. Sin embargo, esto causaría confusión con "Cascading Style Sheets", por lo que el uso de este acrónimo ha disminuido significativamente. Utilice herramientas de análisis estático automatizadas que se centren en este tipo de debilidades. Muchas técnicas modernas utilizan el análisis de flujo de datos para minimizar el número de falsos positivos. Esta no es una solución perfecta, ya que la precisión y la cobertura del 100% no son factibles, especialmente cuando hay múltiples componentes involucrados. Utilice la hoja de trucos XSS [REF-714] o las herramientas de generación de pruebas automatizadas para ayudar a lanzar una amplia variedad de ataques contra su aplicación web. La hoja de trucos contiene muchas variaciones sutiles de XSS que están específicamente dirigidas contra las defensas débiles de XSS. Comprenda todas las áreas potenciales en las que pueden entrar entradas no confiables en su software: parámetros o argumentos, cookies, cualquier cosa leída de la red, variables de entorno, búsquedas inversas de DNS, resultados de consultas, cabeceras de peticiones, componentes de URL, correo electrónico, archivos, nombres de archivos, bases de datos y cualquier sistema externo que proporcione datos a la aplicación. Recuerde que estas entradas pueden obtenerse indirectamente a través de llamadas a la API. Para cualquier comprobación de seguridad que se realice en el lado del cliente, asegúrese de que estas comprobaciones se duplican en el lado del servidor, con el fin de evitar el CWE-602. Los atacantes pueden eludir las comprobaciones del lado del cliente modificando los valores después de que se hayan realizado las comprobaciones, o cambiando el cliente para eliminar las comprobaciones del lado del cliente por completo. Entonces, estos valores modificados se enviarían al servidor. Si está disponible, utilice mecanismos estructurados que impongan automáticamente la separación entre datos y código. Estos mecanismos pueden ser capaces de proporcionar las citas pertinentes, la codificación y la validación de forma automática, en lugar de confiar en el desarrollador para proporcionar esta capacidad en cada punto donde se genera la salida. Con Struts, escriba todos los datos de los beans de formulario con el atributo filter del bean establecido en true. Para ayudar a mitigar los ataques XSS contra la cookie de sesión del usuario, configure la cookie de sesión para que sea HttpOnly. En los navegadores que soportan la función HttpOnly (como las versiones más recientes de Internet Explorer y Firefox), este atributo puede evitar que la cookie de sesión del usuario sea accesible a los scripts maliciosos del lado del cliente que utilizan document.cookie. Esta no es una solución completa, ya que HttpOnly no es soportado por todos los navegadores. Más importante aún, XMLHTTPRequest y otras potentes tecnologías de los navegadores proporcionan acceso de lectura a las cabeceras HTTP, incluyendo la cabecera Set-Cookie en la que se establece la bandera HttpOnly. Cuando el conjunto de objetos aceptables, como los nombres de archivo o las URL, es limitado o conocido, cree un mapeo desde un conjunto de valores de entrada fijos (como los ID numéricos) hasta los nombres de archivo o las URL reales, y rechace todas las demás entradas. Utilice un cortafuegos de aplicaciones que pueda detectar ataques contra esta debilidad. Puede ser beneficioso en los casos en los que el código no puede ser arreglado (porque es controlado por un tercero), como una medida de prevención de emergencia mientras se aplican medidas de aseguramiento de software más completas, o para proporcionar una defensa en profundidad. Cuando utilice PHP, configure la aplicación para que no utilice register_globals. Durante la implementación, desarrolle la aplicación para que no dependa de esta característica, pero tenga cuidado de implementar una emulación de register_globals que esté sujeta a debilidades como CWE-95, CWE-621, y problemas similares. El gestor de bibliotecas de Python no neutralizaba suficientemente un término de búsqueda suministrado por el usuario, permitiendo un XSS reflejado. La plataforma de comercio electrónico basada en Python no escapaba del contenido devuelto en las páginas de error, lo que permitía ataques de Cross-Site Scripting reflejados. XSS universal en el sistema operativo móvil, explotado in the wild por CISA KEV. Cadena: la validación de entrada inadecuada (CWE-20) en el producto de cortafuegos conduce a XSS (CWE-79), como se explotó en la naturaleza por CISA KEV. La interfaz gráfica de administración permite el XSS a través de una cookie. El programa de estadísticas web permite el XSS a través de una cabecera HTTP manipulada. El producto de análisis de registros web permite el XSS a través del encabezado HTTP Referer. Cadena: el fallo del mecanismo de protección permite el XSS Cadena: la lista de denegación incompleta (CWE-184) sólo comprueba la etiqueta "javascript:", lo que permite el XSS (CWE-79) utilizando otras etiquetas Cadena: la lista de denegación incompleta (CWE-184) sólo elimina las etiquetas SCRIPT, lo que permite el XSS (CWE-79) XSS reflejado utilizando el PATH_INFO en una URL XSS reflejado no gestionado adecuadamente al generar un mensaje de error XSS reflejado enviado a través de un mensaje de correo electrónico. XSS almacenado en un producto de seguridad. XSS almacenado utilizando una página wiki. XSS almacenado en una aplicación de libro de visitas. XSS almacenado en una aplicación de libro de visitas utilizando un javascript: URI en una etiqueta bbcode img. Cadena: el archivo de la biblioteca no está protegido contra una petición directa (CWE-425), lo que lleva a un XSS reflejado (CWE-79).
Referencias
CPE
| cpe |
iniciar |
fin |
| Configuration 1 |
| cpe:2.3:a:foswiki:foswiki:1.1.0:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:foswiki:foswiki:1.1.1:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:foswiki:foswiki:1.1.2:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:foswiki:foswiki:1.1.3:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:foswiki:foswiki:1.1.4:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:foswiki:foswiki:1.1.4:beta:*:*:*:*:*:* |
|
|
| cpe:2.3:a:foswiki:foswiki:1.1.4:rc:*:*:*:*:*:* |
|
|
Explota
Exploit-db.com
| id |
descripción |
fecha |
|
| No hay exploits conocidos |
Otros (github, ...)
| Url |
| No hay exploits conocidos |
CAPEC
| id |
descripción |
gravedad |
| 591 |
XSS reflejado
Este tipo de ataque es una forma de Cross-Site Scripting (XSS) en la que un script malicioso se "refleja" en una aplicación web vulnerable y luego es ejecutado por el navegador de la víctima. El proceso comienza con un adversario que entrega un script malicioso a la víctima y la convence de que envíe el script a la aplicación web vulnerable. [Utilizando un navegador o una herramienta automatizada, un adversario sigue todos los enlaces y acciones públicas en un sitio web. Registra todos los enlaces, los formularios, los recursos a los que se accede y todos los demás puntos de entrada potenciales para la aplicación web. [El adversario utiliza los puntos de entrada recogidos en la fase de "exploración" como una lista de objetivos e inyecta varias cargas útiles de scripts comunes y caracteres especiales para determinar si un punto de entrada representa realmente una vulnerabilidad y para caracterizar el grado en que la vulnerabilidad puede ser explotada. [Una vez que el adversario ha determinado qué parámetros son vulnerables al XSS, elaborará una URL maliciosa que contenga el exploit XSS. El adversario puede tener muchos objetivos, desde robar IDs de sesión, cookies, credenciales y contenido de la página de la víctima. [Para que el ataque tenga éxito, la víctima debe acceder a la URL maliciosa. |
Muy alto |
| 592 |
XSS almacenado
Un adversario utiliza una forma de Cross-site Scripting (XSS) en la que un script malicioso es persistentemente "almacenado" dentro del almacenamiento de datos de una aplicación web vulnerable como entrada válida. [Usando un navegador o una herramienta automatizada, un adversario sigue todos los enlaces y acciones públicas en un sitio web. Registra todos los enlaces, los formularios, los recursos a los que se accede y todos los demás puntos de entrada potenciales de la aplicación web. El adversario busca las áreas donde se almacenan las entradas de los usuarios, como los perfiles de los usuarios, los carros de la compra, los gestores de archivos, los foros, los blogs y los registros. [El adversario utiliza los puntos de entrada recogidos en la fase de "Exploración" como una lista de objetivos e inyecta varias cargas útiles de scripts comunes y caracteres especiales para determinar si un punto de entrada representa realmente una vulnerabilidad y para caracterizar el grado en que la vulnerabilidad puede ser explotada. [Almacenar contenido XSS malicioso] Una vez que el adversario ha determinado qué ubicaciones almacenadas son vulnerables al XSS, interactuará con la aplicación web para almacenar el contenido malicioso. El adversario puede tener muchos objetivos, desde robar IDs de sesión, cookies, credenciales y contenido de la página de la víctima. [Conseguir que la víctima vea el contenido almacenado] Para que el ataque tenga éxito, la víctima necesita ver el contenido malicioso almacenado en la página web. |
Muy alto |
| 85 |
Huella AJAX
Este ataque utiliza los frecuentes viajes de ida y vuelta cliente-servidor en la conversación de Ajax para escanear un sistema. Aunque Ajax no abre nuevas vulnerabilidades en sí, las optimiza desde el punto de vista del atacante. Un primer paso común para un atacante es hacer un footprint del entorno objetivo para entender qué ataques funcionarán. Dado que el footprinting se basa en la enumeración, el patrón conversacional de peticiones y respuestas rápidas y múltiples que son típicas en las aplicaciones Ajax permiten a un atacante buscar muchas vulnerabilidades, puertos conocidos, ubicaciones de red, etc. El conocimiento obtenido a través de la huella digital de Ajax puede utilizarse para apoyar otros ataques, como el XSS. [Enviar solicitudes a la página web objetivo y analizar el HTML] Utilizando un navegador o una herramienta automatizada, un adversario envía solicitudes a una página web y registra la respuesta HTML recibida. A continuación, los adversarios analizan el HTML para identificar cualquier arquitectura JavaScript subyacente conocida. Esto puede ayudar a mapear vulnerabilidades conocidas públicamente a la página web y también puede ayudar al adversario a adivinar la arquitectura de la aplicación y el funcionamiento interno de un sistema. |
Bajo |
| 63 |
Cross-Site Scripting (XSS)
Un adversario incrusta scripts maliciosos en el contenido que se servirá a los navegadores web. El objetivo del ataque es que el software objetivo, el navegador del lado del cliente, ejecute el script con el nivel de privilegio de los usuarios. Un ataque de este tipo se aprovecha de las vulnerabilidades de un programa que permite a los hosts remotos ejecutar código y scripts. Los navegadores web, por ejemplo, disponen de algunos controles de seguridad sencillos, pero si se permite a un atacante remoto ejecutar scripts (inyectándolos en contenidos generados por el usuario, como los tablones de anuncios), estos controles pueden saltarse. Además, estos ataques son muy difíciles de detectar para un usuario final. [Examinar la aplicación en busca de entradas controlables por el usuario] Utilizando un navegador o una herramienta automatizada, un atacante sigue todos los enlaces y acciones públicas en un sitio web. Registra todos los enlaces, los formularios, los recursos a los que se accede y todos los demás puntos de entrada potenciales para la aplicación web. [El atacante utiliza los puntos de entrada recogidos en la fase de "Exploración" como una lista de objetivos e inyecta varias cargas útiles de scripts comunes para determinar si un punto de entrada representa realmente una vulnerabilidad y para caracterizar el grado en que la vulnerabilidad puede ser explotada. [Robo de ID de sesión, credenciales, contenido de la página, etc.] Cuando el atacante consigue explotar la vulnerabilidad, puede optar por robar las credenciales del usuario para reutilizarlas o analizarlas posteriormente. [Navegación forzada] Cuando el atacante se dirige a la aplicación actual o a otra (a través de vulnerabilidades CSRF), el usuario será entonces quien realice los ataques sin ser consciente de ello. Estos ataques se dirigen sobre todo a los fallos de la lógica de la aplicación, pero también puede utilizarse para crear un ataque generalizado contra un sitio web concreto en la red actual del usuario (en Internet o no). [Content spoofing] Al manipular el contenido, el atacante se dirige a la información que el usuario desea obtener del sitio web. |
Muy alto |
| 209 |
XSS Using MIME Type Mismatch
Un adversario crea un archivo con contenido de scripting pero donde el tipo MIME especificado del archivo es tal que no se espera que haya scripting. El adversario engaña a la víctima para que acceda a una URL que responde con el archivo de script. Algunos navegadores detectarán que el tipo MIME especificado del archivo no coincide con el tipo real de su contenido y pasarán automáticamente a utilizar un intérprete para el tipo de contenido real. Si el navegador no invoca los filtros de scripts antes de hacer esto, el script del adversario puede ejecutarse en el objetivo sin ser saneado, posiblemente revelando las cookies de la víctima o ejecutando un script arbitrario en su navegador. [Inspeccionar la aplicación en busca de entradas almacenadas controlables por el usuario] Utilizando un navegador o una herramienta automatizada, un adversario sigue todos los enlaces y acciones públicas en un sitio web. Registran todas las áreas que permiten a un usuario cargar contenido a través de una solicitud HTTP POST. Esto se encuentra típicamente en blogs o foros. [El adversario utiliza los puntos de entrada recogidos en la fase de "Exploración" como una lista de objetivos y sube archivos con contenido de scripting, pero cuyo tipo MIME está especificado como un tipo de archivo que no puede ejecutar contenido de scripting. Si la aplicación sólo comprueba el tipo MIME del archivo, puede dejar pasar el archivo, haciendo que el script sea ejecutado por cualquier usuario que acceda al archivo. [Una vez que el adversario ha determinado qué ubicaciones de carga de archivos son vulnerables a la falta de coincidencia del tipo MIME, subirá un script malicioso disfrazado como un archivo que no es de scripting. El adversario puede tener muchos objetivos, desde robar IDs de sesión, cookies, credenciales y contenido de la página de la víctima. [Conseguir que la víctima vea el contenido almacenado] Para que el ataque tenga éxito, la víctima necesita ver el contenido malicioso almacenado en la página web. |
Medio |
| 588 |
DOM-Based XSS
Este tipo de ataque es una forma de Cross-Site Scripting (XSS) en la que se inserta un script malicioso en el HTML del lado del cliente que está siendo analizado por un navegador web. El contenido servido por una aplicación web vulnerable incluye código de script utilizado para manipular el Modelo de Objetos del Documento (DOM). Este código de script no valida correctamente la entrada o no realiza una codificación de salida adecuada, creando así una oportunidad para que un adversario inyecte un script malicioso y lance un ataque XSS. Una distinción clave entre otros ataques XSS y los ataques basados en el DOM es que en otros ataques XSS, el script malicioso se ejecuta cuando la página web vulnerable se carga inicialmente, mientras que un ataque basado en el DOM se ejecuta en algún momento después de la carga de la página. Otra distinción de los ataques basados en el DOM es que, en algunos casos, el script malicioso nunca se envía al servidor web vulnerable. Un ataque de este tipo está garantizado para eludir cualquier intento de filtrado del lado del servidor para proteger a los usuarios. [Utilizando un navegador o una herramienta automatizada, un adversario sigue todos los enlaces y acciones públicas en un sitio web. Registra todos los enlaces, los formularios, los recursos a los que se accede y todos los demás puntos de entrada potenciales para la aplicación web. [El adversario utiliza los puntos de entrada recogidos en la fase de "Exploración" como una lista de objetivos e inyecta varias cargas útiles de scripts comunes y caracteres especiales para determinar si un punto de entrada representa realmente una vulnerabilidad y para caracterizar el grado en que la vulnerabilidad puede ser explotada. Específicamente para el XSS basado en el DOM, el adversario busca áreas donde la entrada se utiliza para cambiar directamente el DOM. [Una vez que el adversario ha determinado qué parámetros son vulnerables al XSS, creará una URL maliciosa que contenga el exploit XSS. El adversario puede tener muchos objetivos, desde robar IDs de sesión, cookies, credenciales y contenido de la página de la víctima. En el XSS basado en el DOM, el script malicioso puede ni siquiera ser enviado al servidor, ya que el navegador de la víctima manipulará el propio DOM. Esto puede ayudar a evitar los mecanismos de detección del lado del servidor. [Para que el ataque tenga éxito, la víctima debe acceder a la URL maliciosa. |
Muy alto |
Sherlock® flash
Haz una foto de tu red informática en unos pocos clics !
La solución de auditoría Sherlock® flash le permite realizar una auditoría para reforzar la seguridad de sus activos informáticos. Escaneo de vulnerabilidad de sus equipos físicos y virtuales. Planificación de parches por nivel de prioridad y tiempo disponible. Informes detallados e intuitivos.
Descubra esta oferta
