2.1 CVE-2012-2075
La vulnerabilidad de cross-site scripting (XSS) en el módulo Contact Save 6.x-1.x antes de 6.x-1.5 para Drupal permite a los usuarios autenticados de forma remota con el permiso de acceso al formulario de contacto de todo el sitio para inyectar un script web arbitrario o HTML a través de no especificado vectores.
https://nvd.nist.gov/vuln/detail/CVE-2012-2075
Categorías
CWE-79 : Neutralización inadecuada de la entrada durante la generación de la página web ('Cross-site Scripting')
El producto no neutraliza o neutraliza incorrectamente la entrada controlable por el usuario antes de que se coloque en la salida que se utiliza como una página web que se sirve a otros usuarios. Abreviatura común de Cross-Site Scripting. 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 de uso común. 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 automatizadas de análisis estático 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. No se trata de una solución perfecta, ya que la precisión y la cobertura del 100% no son factibles, especialmente cuando intervienen múltiples componentes. Utilice la hoja de trucos XSS [REF-714] o herramientas automatizadas de generación de pruebas para ayudar a lanzar una amplia variedad de ataques contra su aplicación web. La hoja de trucos contiene muchas variaciones sutiles de XSS dirigidas específicamente contra defensas XSS débiles. Comprenda todas las áreas potenciales en las que entradas no fiables pueden entrar en su software: parámetros o argumentos, cookies, cualquier cosa leída de la red, variables de entorno, búsquedas DNS inversas, resultados de consultas, cabeceras de peticiones, componentes 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 por completo las comprobaciones del lado del cliente. Entonces, estos valores modificados se enviarían al servidor. Si están disponibles, 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 a 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 scripts maliciosos del lado del cliente que utilicen document.cookie. No se trata de una solución completa, ya que HttpOnly no es compatible con 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 nombres de archivo o URL, sea limitado o conocido, cree una correspondencia entre un conjunto de valores de entrada fijos (como ID numéricos) y los nombres de archivo o URL reales, y rechace todas las demás entradas. Utilice un cortafuegos de aplicaciones que pueda detectar ataques contra este punto débil. Puede ser beneficioso en los casos en los que el código no se puede arreglar (porque está controlado por un tercero), como medida de prevención de emergencia mientras se aplican medidas de aseguramiento de software más exhaustivas, o para proporcionar 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. Python Library Manager no neutralizaba suficientemente un término de búsqueda proporcionado por el usuario, permitiendo 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 sistema operativo móvil, explotado in the wild por CISA KEV. Cadena: la validación de entrada incorrecta (CWE-20) en el cortafuegos da lugar a XSS (CWE-79), explotado in the wild según CISA KEV. Admin GUI permite XSS a través de cookie. El programa de estadísticas web permite XSS a través de un encabezado HTTP manipulado. Un producto de análisis de registros web permite el uso de XSS a través de un encabezado HTTP Referer manipulado. Cadena: fallo del mecanismo de protección permite XSS Cadena: denylist incompleta (CWE-184) sólo comprueba la etiqueta "javascript:", permitiendo XSS (CWE-79) utilizando otras etiquetas Cadena: denylist incompleta (CWE-184) sólo elimina las etiquetas SCRIPT, permitiendo XSS (CWE-79) XSS reflejado utilizando el PATH_INFO en una URL XSS reflejado no gestionado correctamente 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 mediante javascript: URI en una etiqueta bbcode img. Cadena: archivo de biblioteca no está protegido contra una solicitud directa (CWE-425), lo que lleva a XSS reflejado (CWE-79).
Referencias
BID
CONFIRM Patch Exploit
MISC Patch
OSVDB
SECUNIA
XF
_MLIST
CPE
| cpe |
iniciar |
fin |
| Configuration 1 |
| cpe:2.3:a:steindom:contact_save:6.x-1.0:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.1:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.1:beta1:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.2:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.2:beta1:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.2:beta2:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.2:beta3:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.3:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.3:beta1:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.3:beta2:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.3:beta3:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.4:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.4:beta1:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.4:beta2:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.5:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:steindom:contact_save:6.x-1.x:dev:*:*:*:*:*:* |
|
|
| Running on/with |
| cpe:2.3:a:drupal:drupal:-:*:*:*:*:*:*:* |
|
|
REMEDIACIÓN
Patch
EXPLOTA
Exploit-db.com
| id |
descripción |
fecha |
|
| No hay exploits conocidos |
Otros (github, ...)
CAPEC
Common Attack Pattern Enumerations and Classifications
| id |
descripción |
gravedad |
| 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 |
| 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 |
| 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 |
| 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 |
MITRE
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
