1.2 CVE-2011-2724

Este patrón de ataque consiste en provocar un desbordamiento de búfer mediante la manipulación de variables de entorno. Una vez que el adversario descubre que puede modificar una variable de entorno, puede intentar desbordar los búferes asociados. Este ataque aprovecha la confianza implícita que a menudo se deposita en las variables de entorno. [Identificar la aplicación objetivo] El adversario identifica una aplicación o programa objetivo para realizar el desbordamiento del búfer. En este ataque, el adversario busca una aplicación que cargue el contenido de una variable de entorno en un búfer. [Encontrar el vector de inyección] El adversario identifica un vector de inyección para entregar el contenido excesivo al búfer de la aplicación objetivo. [Elaborar el contenido de desbordamiento] El adversario elabora el contenido a inyectar. Si la intención es simplemente provocar la caída del software, el contenido sólo debe consistir en una cantidad excesiva de datos aleatorios. Si la intención es aprovechar el desbordamiento para la ejecución de código arbitrario, el adversario diseña la carga útil de tal manera que la dirección de retorno sobrescrita es reemplazada por una de su elección. [Desbordamiento del búfer] Utilizando el vector de inyección, el adversario inyecta el contenido de desbordamiento creado en el búfer.

Un atacante puede utilizar la inyección del lado del servidor (SSI) para enviar código a una aplicación web que luego es ejecutado por el servidor web. Esto permite al atacante lograr resultados similares a los del Cross Site Scripting, es decir, la ejecución de código arbitrario y la divulgación de información, aunque a una escala más limitada, ya que las directivas SSI no son ni de lejos tan potentes como un lenguaje de scripting completo. No obstante, el atacante puede acceder cómodamente a archivos sensibles, como los de contraseñas, y ejecutar comandos de shell. [Determinar la aplicabilidad] El adversario determina si los server side includes están habilitados en el servidor web objetivo. [Encontrar el punto de inyección] Buscar la entrada controlable por el usuario, incluyendo las cabeceras HTTP, que pueden llevar directivas de inclusión del lado del servidor al servidor web. [Inyectar SSI] Usando el punto de inyección encontrado, el adversario envía código arbitrario para ser incluido por la aplicación en el lado del servidor. A continuación, puede necesitar ver una página concreta para que el servidor ejecute la directiva de inclusión y ejecute un comando o abra un archivo en nombre del adversario.

Un atacante es capaz de hacer que una víctima cargue contenido en su navegador web que evite los controles de la zona de seguridad y obtenga acceso a privilegios aumentados para ejecutar código de scripting u otros objetos web como controles ActiveX o applets no firmados. Se trata de un ataque de elevación de privilegios dirigido a la seguridad de los navegadores web basados en zonas. [Encuentre sistemas susceptibles al ataque] Encuentre sistemas que contengan funcionalidad a la que se acceda tanto desde la zona de Internet como desde la zona local. Tiene que haber una manera de suministrar entrada a esa funcionalidad desde la zona de Internet y esa entrada original tiene que ser utilizada más tarde en una página de una zona local. [Encontrar el punto de inserción de la carga útil] El atacante primero necesita encontrar alguna funcionalidad del sistema o posiblemente otra debilidad en el sistema (por ejemplo, la susceptibilidad al cross site scripting) que proporcionaría al atacante un mecanismo para entregar la carga útil (es decir, el código a ejecutar) al usuario. La ubicación desde la que se ejecuta este código en el navegador del usuario tiene que estar dentro de la zona de la máquina local. [Desarrollar la carga útil para que se ejecute en la zona de mayor privilegio en el navegador del usuario. Inyecta la carga útil e intenta atraer a la víctima (si es posible) para que ejecute la funcionalidad que libera la carga útil.

Un atacante utiliza métodos estándar de inyección SQL para inyectar datos en la línea de comandos para su ejecución. Esto podría hacerse directamente a través del uso indebido de directivas como MSSQL_xp_cmdshell o indirectamente a través de la inyección de datos en la base de datos que serían interpretados como comandos del shell. En algún momento posterior, una aplicación backend sin escrúpulos (o podría ser parte de la funcionalidad de la misma aplicación) recupera los datos inyectados almacenados en la base de datos y utiliza estos datos como argumentos de línea de comandos sin realizar la validación adecuada. Los datos maliciosos escapan de ese plano de datos generando nuevos comandos que se ejecutan en el host. [El atacante inyecta sintaxis SQL en entradas de datos controlables por el usuario para buscar la ejecución no filtrada de la sintaxis SQL en una consulta. [Lograr la ejecución de comandos arbitrarios a través de la Inyección SQL con la directiva MSSQL_xp_cmdshell] El atacante aprovecha un ataque de Inyección SQL para inyectar código shell a ser ejecutado aprovechando la directiva xp_cmdshell. [Inyectar datos maliciosos en la base de datos] El atacante aprovecha la inyección SQL para inyectar datos en la base de datos que posteriormente podrían ser utilizados para lograr la inyección de comandos si alguna vez se utilizan como argumento de la línea de comandos [Desencadenar la ejecución de la línea de comandos con los argumentos inyectados] El atacante provoca la ejecución de la funcionalidad de la línea de comandos que aprovecha el contenido de la base de datos previamente inyectado como argumentos.

Un atacante aprovecha una debilidad presente en el código de la capa de acceso a la base de datos generado con una herramienta de mapeo relacional de objetos (ORM) o una debilidad en la forma en que un desarrollador utilizó un marco de persistencia para inyectar sus propios comandos SQL que se ejecutan contra la base de datos subyacente. El ataque aquí es similar a la inyección SQL simple, excepto que la aplicación no utiliza JDBC para hablar directamente con la base de datos, sino que utiliza una capa de acceso a datos generada por una herramienta o marco ORM (por ejemplo, Hibernate). Aunque la mayoría de las veces el código generado por una herramienta ORM contiene métodos de acceso seguros que son inmunes a la inyección SQL, a veces, debido a alguna debilidad en el código generado o al hecho de que el desarrollador no utilizó correctamente los métodos de acceso generados, la inyección SQL sigue siendo posible. Determinar el marco de persistencia utilizado] Un atacante intenta determinar qué marco de persistencia es utilizado por la aplicación para aprovechar una debilidad en el código de la capa de acceso a datos generada o una debilidad en la forma en que la capa de acceso a datos puede haber sido utilizada por el desarrollador. [Probar vulnerabilidades de Inyección ORM] El atacante inyecta sintaxis ORM en las entradas de datos controlables por el usuario de la aplicación para determinar si es posible modificar la estructura y el contenido de las consultas de datos. Realizar Inyección SQL a través de la capa de acceso a datos generada] El atacante procede a explotar una debilidad en los métodos de acceso a datos generados que no separa adecuadamente el plano de control del plan de datos, o potencialmente una forma particular en la que el desarrollador podría haber hecho un mal uso del código generado, para modificar la estructura de las consultas SQL ejecutadas y/o inyectar consultas SQL completamente nuevas.

Un atacante modifica los parámetros del mensaje SOAP que se envía desde el consumidor de servicios al proveedor de servicios para iniciar un ataque de inyección SQL. En el lado del proveedor de servicios, el mensaje SOAP es analizado y los parámetros no son validados adecuadamente antes de ser utilizados para acceder a una base de datos de una manera que no utiliza la vinculación de parámetros, lo que permite al atacante controlar la estructura de la consulta SQL ejecutada. Este patrón describe un ataque de inyección SQL cuyo mecanismo de entrega es un mensaje SOAP. El atacante manipula los parámetros del mensaje SOAP y busca indicios de que la manipulación ha provocado un cambio en el comportamiento de la aplicación objetivo. [Probe for SQL Injection vulnerability] El atacante inyecta sintaxis SQL en los parámetros SOAP vulnerables identificados durante la fase de Exploración para buscar la ejecución no filtrada de la sintaxis SQL en una consulta. Inyectar SQL a través de parámetros SOAP] El atacante inyecta SQL a través de parámetros SOAP identificados como vulnerables durante la fase Explore para lanzar un ataque de inyección SQL de primer o segundo orden.

El adversario utiliza una repetición del proceso de codificación de un conjunto de caracteres (es decir, la codificación de un carácter) para ofuscar la carga útil de una solicitud concreta. Esto puede permitir al adversario eludir los filtros que intentan detectar caracteres o cadenas ilegales, como los que podrían utilizarse en ataques de travesía o de inyección. Los filtros pueden ser capaces de detectar cadenas codificadas ilegales, pero pueden no detectar cadenas doblemente codificadas. Por ejemplo, un punto (.), a menudo utilizado en ataques de travesía de rutas y, por tanto, a menudo bloqueado por los filtros, podría estar codificado en la URL como %2E. Sin embargo, muchos filtros reconocen esta codificación y seguirían bloqueando la petición. En una codificación doble, el % en la codificación de URL anterior se codificaría de nuevo como %25, lo que daría como resultado %252E que algunos filtros podrían no captar, pero que aún podría ser interpretado como un punto (.) por los intérpretes en el objetivo. [Examinar la aplicación en busca de entradas controlables por el usuario] Utilizando un navegador, una herramienta automatizada o inspeccionando la aplicación, un atacante registra todos los puntos de entrada a la aplicación. Prueba los puntos de entrada para localizar las vulnerabilidades] Intenta la doble codificación de partes de la entrada para intentar pasar los filtros. Por ejemplo, mediante la doble codificación de ciertos caracteres en la URL (por ejemplo, puntos y barras) un adversario puede intentar acceder a recursos restringidos en el servidor web o forzar la navegación a páginas protegidas (subvirtiendo así el servicio de autorización). Un adversario también puede intentar otros ataques de estilo de inyección utilizando este patrón de ataque: inyección de comandos, inyección SQL, etc.

El adversario modifica directa o indirectamente las variables de entorno utilizadas por el software objetivo o que lo controlan. El objetivo del adversario es hacer que el software objetivo se desvíe de su funcionamiento esperado de manera que beneficie al adversario. [El adversario primero sondea la aplicación objetivo para determinar información importante sobre el objetivo. Esta información podría incluir los tipos de software utilizados, las versiones de software, qué entradas de usuario consume la aplicación, etc. Lo más importante es que el adversario intenta determinar qué variables de entorno podría utilizar el software subyacente, o incluso la propia aplicación. [Usando la información encontrada al sondear la aplicación, el adversario intenta manipular cualquier variable de entorno controlada por el usuario que haya encontrado que está siendo utilizada por la aplicación, o que sospeche que está siendo utilizada por la aplicación, y observar los efectos de estos cambios. Si el adversario nota algún cambio significativo en la aplicación, sabrá que una determinada variable de entorno es importante para el comportamiento de la aplicación e indica un posible vector de ataque. [Manipular variables de entorno controladas por el usuario] El adversario manipula la(s) variable(s) de entorno encontrada(s) para abusar del flujo normal de los procesos o para obtener acceso a recursos privilegiados.

Un adversario incluye caracteres de formato en un campo de entrada de cadena en la aplicación objetivo. La mayoría de las aplicaciones asumen que los usuarios proporcionarán un texto estático y pueden responder de forma impredecible a la presencia de un carácter de formato. Por ejemplo, en ciertas funciones de los lenguajes de programación C como printf, el carácter de formato %s imprimirá el contenido de una ubicación de memoria esperando que esta ubicación identifique una cadena y el carácter de formato %n imprime el número de DWORD escritos en la memoria. Un adversario puede utilizar esto para leer o escribir en ubicaciones de memoria o archivos, o simplemente para manipular el valor del texto resultante de forma inesperada. La lectura o escritura de memoria puede resultar en la caída del programa y la escritura de memoria podría resultar en la ejecución de código arbitrario si el adversario puede escribir en la pila del programa. El adversario hace un inventario de los puntos de entrada de la aplicación. Determina la entrada controlable por el usuario susceptible de inyección de cadenas de formato] Determina la entrada controlable por el usuario susceptible de inyección de cadenas de formato. Para cada entrada controlable por el usuario que el adversario sospecha que es vulnerable a la inyección de cadenas de formato, intenta inyectar caracteres de formato como %n, %s, etc. El objetivo es manipular la creación de la cadena utilizando estos caracteres de formato. Después de determinar que una entrada dada es vulnerable a la inyección de cadenas de formato, hipoteque cómo es el uso subyacente y las restricciones asociadas.

Un atacante manipula o crea una consulta LDAP con el propósito de socavar la seguridad del objetivo. Algunas aplicaciones utilizan la entrada del usuario para crear consultas LDAP que son procesadas por un servidor LDAP. Por ejemplo, un usuario puede proporcionar su nombre de usuario durante la autenticación y el nombre de usuario puede ser insertado en una consulta LDAP durante el proceso de autenticación. Un atacante podría utilizar esta entrada para inyectar comandos adicionales en una consulta LDAP que podría revelar información sensible. Por ejemplo, introducir un * en la consulta mencionada podría devolver información sobre todos los usuarios del sistema. Este ataque es muy similar a un ataque de inyección SQL en el sentido de que manipula una consulta para obtener información adicional o coaccionar un valor de retorno particular. [El atacante hace un inventario de los puntos de entrada de la aplicación. [Determina la entrada controlable por el usuario susceptible de inyección LDAP] Para cada entrada controlable por el usuario que el atacante sospecha que es vulnerable a la inyección LDAP, intenta inyectar caracteres que tienen un significado especial en LDAP (como un carácter de comilla simple, etc.). El objetivo es crear una consulta LDAP con una sintaxis no válida [Intentar explotar la vulnerabilidad de la inyección LDAP] Después de determinar que una entrada dada es vulnerable a la inyección LDAP, hipotetizar cómo es la consulta subyacente. Posiblemente usando una herramienta, intente iterativamente añadir lógica a la consulta para extraer información del LDAP, o para modificar o borrar información en el LDAP.

Este tipo de ataque explota una vulnerabilidad de desbordamiento de búfer en el software cliente objetivo a través de la inyección de contenido malicioso desde un servicio hostil construido a medida. Este servicio hostil se crea para entregar el contenido correcto al software cliente. Por ejemplo, si la aplicación del lado del cliente es un navegador, el servicio alojará una página web que el navegador carga. [Identificar la aplicación cliente objetivo] El adversario identifica una aplicación cliente objetivo para realizar el desbordamiento del búfer. Las más comunes son los navegadores. Si hay una vulnerabilidad conocida en el navegador, el adversario podría apuntar a ella. [Encontrar el vector de inyección] El adversario identifica un vector de inyección para entregar el contenido excesivo al buffer de la aplicación objetivo. [Crear un servicio hostil] El adversario crea un servicio hostil que entregará el contenido a la aplicación del lado del cliente. Si la intención es simplemente hacer que el software se bloquee, el contenido sólo tiene que consistir en una cantidad excesiva de datos aleatorios. Si la intención es aprovechar el desbordamiento para la ejecución de código arbitrario, el adversario diseña la carga útil de tal manera que la dirección de retorno sobrescrita es reemplazada por una de su elección. [Desbordamiento del búfer] Utilizando el vector de inyección, el adversario entrega el contenido a la aplicación del lado del cliente que utiliza el servicio hostil y desborda el búfer.

Un atacante explota una debilidad en la validación de entrada controlando el formato, la estructura y la composición de los datos a una interfaz de procesamiento de entrada. Al suministrar una entrada de forma no estándar o inesperada, un atacante puede afectar negativamente a la seguridad del objetivo.

Un atacante engaña a una víctima para que ejecute contenido flash malicioso que ejecuta comandos o realiza llamadas flash especificadas por el atacante. Un ejemplo de este ataque es el cross-site flashing, un parámetro controlado por el atacante a una llamada de referencia carga de contenido especificado por el atacante. [Encontrar los puntos de entrada de la inyección] El atacante primero hace un inventario de los puntos de entrada de la aplicación. [Determina la susceptibilidad de la aplicación a la inyección de Flash] Determina la susceptibilidad de la aplicación a la inyección de Flash. Para cada URL identificada en la fase de exploración, el atacante intenta utilizar varias técnicas, como la carga directa como función, la página maligna controlada/host, la inyección de Flash HTML y la inyección DOM para determinar si la aplicación es susceptible de inyección de Flash. [Inyectar contenido malicioso en el objetivo] Inyectar contenido malicioso en el objetivo utilizando vectores de inyección vulnerables identificados en la fase de Experimentación

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.

Un ataque de este tipo aprovecha las vulnerabilidades en la autenticación del canal de comunicación cliente/servidor y la integridad de los datos. Aprovecha la confianza implícita que un servidor deposita en el cliente, o más aún, lo que el servidor cree que es el cliente. Un atacante ejecuta este tipo de ataque comunicándose directamente con el servidor cuando éste cree que se está comunicando sólo con un cliente válido. Existen numerosas variantes de este tipo de ataque.

Un adversario envenena los archivos con una carga útil maliciosa (dirigida a los sistemas de archivos accesibles por el software de destino), que puede ser transmitida por canales estándar como el correo electrónico, y contenido web estándar como PDF y archivos multimedia. El adversario aprovecha las vulnerabilidades conocidas o las rutinas de manejo en los procesos objetivo, con el fin de explotar la confianza del anfitrión en la ejecución de contenidos remotos, incluyendo archivos binarios.

Las aplicaciones a menudo necesitan transformar los datos dentro y fuera de un formato de datos (por ejemplo, XML y YAML) mediante el uso de un analizador. Puede ser posible que un adversario inyecte datos que puedan tener un efecto adverso en el analizador sintáctico cuando se está procesando. Muchos lenguajes de formato de datos permiten la definición de estructuras tipo macro que pueden utilizarse para simplificar la creación de estructuras complejas. Al anidar estas estructuras, haciendo que los datos se sustituyan repetidamente, un adversario puede hacer que el analizador sintáctico consuma más recursos durante el procesamiento, provocando un consumo excesivo de memoria y de la CPU. Un adversario determina el flujo de datos de entrada que está siendo procesado por un analizador de datos que soporta el uso de la sustitución en el lado de la víctima. Un adversario crea datos de entrada que pueden tener un efecto adverso en el funcionamiento del analizador sintáctico cuando los datos se analizan en el sistema de la víctima.

Un adversario inyecta cargas útiles de datos serializados de gran tamaño en un analizador durante el procesamiento de datos para producir efectos adversos en el analizador, como el agotamiento de los recursos del sistema y la ejecución de código arbitrario. Un adversario determina el flujo de datos de entrada que está siendo procesado por un analizador de datos serializados en el lado de la víctima. Un adversario elabora datos de entrada que pueden tener un efecto adverso en el funcionamiento del analizador de datos cuando los datos se analizan en el sistema de la víctima.

En este ataque, la idea es hacer fallar un filtro activo provocando una transacción sobredimensionada. Un atacante puede tratar de alimentar cadenas de entrada demasiado largas al programa en un intento de abrumar al filtro (causando un desbordamiento del búfer) y esperando que el filtro no falle de forma segura (es decir, la entrada del usuario se deja en el sistema sin filtrar). [Inspección] El atacante inspecciona la aplicación objetivo, posiblemente como un usuario válido y autenticado [Intentar inyecciones] Intenta introducir datos demasiado largos en el sistema. Esto se puede hacer manualmente o se puede utilizar una herramienta dinámica (caja negra) para automatizarlo. Un atacante también puede utilizar un script personalizado para este propósito. [Supervisar las respuestas] Vigilar cualquier indicación de que se produzcan fallos. Observe cuidadosamente para ver qué ocurrió cuando se produjo el fallo del filtro. ¿Llegaron los datos? [Abusar del sistema a través del fallo del filtro] Un atacante escribe un script para inducir sistemáticamente el fallo del filtro.

Un atacante utiliza la entrada controlable por el usuario de XML para sondear, atacar e inyectar datos en la base de datos XML, utilizando técnicas similares a la inyección SQL. La entrada controlable por el usuario puede permitir la visualización no autorizada de los datos, eludiendo la autenticación o la aplicación front-end para el acceso directo a la base de datos XML, y posiblemente alterando la información de la base de datos. [Estudio del objetivo] Utilizando un navegador o una herramienta automatizada, un adversario registra todas las instancias de entrada controlable por el usuario utilizadas para construir consultas XML [Determinar la estructura de las consultas] Utilizando medios manuales o automatizados, prueba las entradas encontradas para detectar debilidades en XML. [Inyectar contenido en las consultas XML] Crear contenido malicioso con expresiones XML que no sea validado por la aplicación y que se ejecute como parte de las consultas XML.

Un adversario que está autorizado a enviar consultas a un objetivo envía variantes de las consultas esperadas con la esperanza de que estas consultas modificadas puedan devolver información (directa o indirectamente a través de registros de errores) más allá de lo que el conjunto de consultas esperadas debería proporcionar. [Observar la comunicación y las entradas] El adversario de fuzzing observa el sistema objetivo buscando entradas y comunicaciones entre módulos, subsistemas o sistemas. [Generar entradas de fuzzing] Dada una herramienta de fuzzing, una entrada o protocolo objetivo y límites de tiempo, complejidad y variedad de entradas, genera una lista de entradas para probar. Aunque el fuzzing es aleatorio, no es exhaustivo. Parámetros como la longitud, la composición y el número de variaciones a probar son importantes para obtener el impacto más rentable del fuzzer. [Observar el resultado] Observar las salidas de las entradas introducidas en el sistema por los fuzzers y ver si hay algún mensaje de registro o de error que proporcione datos de usuario/sensibles o que dé información sobre una plantilla esperada que pueda ser utilizada para producir estos datos. [Si los registros no revelan ningún dato de usuario/sensible, un adversario intentará hacer que las entradas de los fuzzers se ajusten a una plantilla esperada.

Un adversario aprovecha la posibilidad de codificar la entrada o el contenido potencialmente dañino utilizado por las aplicaciones, de manera que éstas sean ineficaces para validar este estándar de codificación. [Inspeccionar la aplicación en busca de entradas controlables por el usuario] Utilizando un navegador, una herramienta automatizada o inspeccionando la aplicación, un adversario registra todos los puntos de entrada a la aplicación. [El adversario utiliza los puntos de entrada recogidos en la fase de "Exploración" como una lista de objetivos e inyecta varias cargas útiles utilizando una variedad de diferentes tipos de codificaciones para determinar si un punto de entrada representa realmente una vulnerabilidad con una lógica de validación insuficiente y para caracterizar el grado en que la vulnerabilidad puede ser explotada.

En este patrón de ataque, el adversario aprovecha el fuzzing para tratar de identificar debilidades en el sistema. El fuzzing es un método de pruebas de seguridad y funcionalidad del software que introduce en el sistema una entrada construida al azar y busca una indicación de que se ha producido un fallo en respuesta a esa entrada. El fuzzing trata el sistema como una caja negra y está totalmente libre de cualquier preconcepción o suposición sobre el sistema. El fuzzing puede ayudar a un atacante a descubrir ciertas suposiciones hechas sobre la entrada del usuario en el sistema. El fuzzing proporciona a un atacante una forma rápida de descubrir potencialmente algunas de estas suposiciones a pesar de no saber necesariamente nada sobre el interior del sistema. Estas suposiciones pueden volverse en contra del sistema mediante la creación de entradas de usuario especiales que permitan al atacante alcanzar sus objetivos. Observar la comunicación y las entradas] El atacante de fuzzing observa el sistema objetivo buscando entradas y comunicaciones entre módulos, subsistemas o sistemas. Generar entradas de fuzzing] Dada una herramienta de fuzzing, una entrada o protocolo objetivo y límites de tiempo, complejidad y variedad de entradas, genera una lista de entradas para probar. Aunque el fuzzing es aleatorio, no es exhaustivo. Parámetros como la longitud, la composición y el número de variaciones a probar son importantes para obtener el impacto más rentable del fuzzer. Observar el resultado] Observar las salidas a las entradas introducidas en el sistema por los fuzzers y ver si ocurre algo interesante. Si se produce un fallo, determine por qué ha ocurrido. Averiguar la suposición subyacente que fue invalidada por la entrada. Introducir en el sistema una entrada especialmente diseñada que aproveche la debilidad identificada mediante el fuzzing y permita alcanzar los objetivos del atacante. Los fuzzers a menudo revelan formas de colarse a través de los filtros de validación de entrada e introducir datos no deseados en el sistema.

Algunas APIs eliminan ciertos caracteres iniciales de una cadena de parámetros. Un adversario puede introducir intencionadamente caracteres iniciales "fantasma" (caracteres adicionales que no afectan a la validez de la solicitud en la capa de la API) que permiten que la entrada pase los filtros y, por tanto, procese la entrada del adversario. Esto ocurre cuando la API objetivo acepta datos de entrada en varias formas sintácticas y los interpreta de forma semántica equivalente, mientras que el filtro no tiene en cuenta todo el espectro de las formas sintácticas aceptables para la API objetivo. [Inspeccionar la aplicación en busca de entradas controlables por el usuario] Utilizando un navegador, una herramienta automatizada o inspeccionando la aplicación, un adversario registra todos los puntos de entrada a la aplicación. [El adversario utiliza los puntos de entrada recogidos en la fase de "exploración" como una lista de objetivos e inyecta varias secuencias de caracteres "fantasma" para determinar cómo los filtra la aplicación. [El adversario utiliza lo que ha aprendido acerca de cómo la aplicación filtra los datos de entrada, y elabora datos de entrada específicos que eluden el filtro. Esto puede conducir a ataques de cruce de directorios, ejecución de comandos arbitrarios de la shell, corrupción de archivos, etc.

Este ataque se basa en el uso de cookies HTTP para almacenar credenciales, información de estado y otros datos críticos en los sistemas cliente. Hay varias formas diferentes de este ataque. La primera forma de este ataque consiste en acceder a las cookies HTTP para minar los datos potencialmente sensibles que contienen. La segunda forma consiste en interceptar estos datos mientras se transmiten del cliente al servidor. Esta información interceptada es entonces utilizada por el adversario para hacerse pasar por el usuario/sesión remoto. La tercera forma es cuando el contenido de la cookie es modificado por el adversario antes de ser enviado de vuelta al servidor. En este caso, el adversario trata de convencer al servidor de destino para que opere con esta información falsificada. Obtener una copia de la cookie] El adversario necesita primero obtener una copia de la cookie. El adversario puede ser un usuario final legítimo que quiere escalar privilegios, o podría ser alguien que husmea en una red para obtener una copia de las cookies HTTP. Obtener información sensible de la cookie] El adversario puede ser capaz de obtener información sensible de la cookie. Los desarrolladores de la aplicación web pueden haber asumido que las cookies no son accesibles para los usuarios finales, y por lo tanto, pueden haber puesto información potencialmente sensible en ellas. Modificar la cookie para subvertir los controles de seguridad] El adversario puede ser capaz de modificar o reemplazar las cookies para saltarse los controles de seguridad de la aplicación.

Un atacante aprovecha una debilidad en la rutina de conversión de MIME para provocar un desbordamiento del búfer y obtener el control de la máquina del servidor de correo. El sistema MIME está diseñado para permitir que varios formatos de información diferentes sean interpretados y enviados por correo electrónico. Existen puntos de ataque cuando los datos se convierten a un formato compatible con MIME y viceversa. [Identificar el servidor de correo objetivo] El adversario identifica un servidor de correo objetivo que desea atacar. [Determinar la viabilidad del ataque] Determinar si el servidor de correo no tiene parches y es potencialmente vulnerable a uno de los desbordamientos de búfer de conversión MIME conocidos (por ejemplo, Sendmail 8.8.3 y 8.8.4). [Encontrar el vector de inyección] Identificar los lugares del sistema donde se pueden utilizar las rutinas de conversión MIME vulnerables. [El adversario crea mensajes de correo electrónico con cabeceras especiales que causarán un desbordamiento del búfer para la rutina de conversión MIME vulnerable. La intención de este ataque es aprovechar el desbordamiento para la ejecución de código arbitrario y obtener acceso a la máquina del servidor de correo, por lo que el adversario elaborará un correo electrónico que no sólo desborda el búfer objetivo, sino que lo hace de tal manera que la dirección de retorno sobrescrita se sustituye por una de su elección. [Desbordar el búfer] Enviar mensajes de correo electrónico al sistema objetivo con cabeceras especialmente diseñadas que desencadenen el desbordamiento del búfer y ejecuten el código shell.

Un atacante suministra al software de destino datos de entrada que contienen secuencias de caracteres especiales diseñadas para eludir la lógica de validación de entrada. Este exploit se basa en que el objetivo hace varias pasadas sobre los datos de entrada y procesa una "capa" de caracteres especiales con cada pasada. De esta manera, el atacante puede disfrazar una entrada que de otro modo sería rechazada como inválida, ocultándola con capas de caracteres especiales/de escape que son eliminados en los pasos de procesamiento posteriores. El objetivo es descubrir primero los casos en los que la capa de validación de entrada se ejecuta antes de una o más capas de análisis. Es decir, la entrada del usuario puede pasar por la siguiente lógica en una aplicación: <parser1> --> <validador de entrada> --> <parser2>. En estos casos, el atacante necesitará proporcionar una entrada que pase por el validador de entrada, pero que después de pasar por el parser2, se convierta en algo que el validador de entrada debía detener. [Determinar las entradas de la aplicación/sistema en las que se desea eludir la validación de entrada] El atacante necesita primero determinar todas las entradas de la aplicación/sistema en las que se está realizando la validación de entrada y en las que quiere eludirla. [Determinar qué codificaciones de caracteres son aceptadas por la aplicación/sistema] El atacante necesita entonces proporcionar varias codificaciones de caracteres a la aplicación/sistema y determinar cuáles son aceptadas. El atacante tendrá que observar la respuesta de la aplicación/sistema a los datos codificados para determinar si los datos fueron interpretados correctamente. [Combinar múltiples codificaciones aceptadas por la aplicación] El atacante combina ahora las codificaciones aceptadas por la aplicación. El atacante puede combinar diferentes codificaciones o aplicar la misma codificación varias veces. [El atacante aprovecha su capacidad para eludir la validación de entradas para obtener un acceso no autorizado al sistema. Hay muchos ataques posibles, y aquí se mencionan algunos ejemplos.

Este tipo de ataque aprovecha el uso de enlaces simbólicos para provocar desbordamientos de búfer. Un adversario puede intentar crear o manipular un archivo de enlace simbólico de manera que su contenido dé lugar a datos fuera de los límites. Cuando el software de destino procesa el archivo de enlace simbólico, podría desbordar los búferes internos con una comprobación de límites insuficiente. [Identificar la aplicación objetivo] El adversario identifica una aplicación o programa objetivo que podría cargar ciertos archivos en la memoria. [Encontrar el vector de inyección] El adversario identifica un vector de inyección para entregar el contenido excesivo al búfer de la aplicación objetivo. [Elaborar el contenido del archivo de desbordamiento] El adversario elabora el contenido que se va a inyectar. Si la intención es simplemente provocar la caída del software, el contenido sólo debe consistir en una cantidad excesiva de datos aleatorios. Si la intención es aprovechar el desbordamiento para la ejecución de código arbitrario, el adversario diseña la carga útil de tal manera que la dirección de retorno sobrescrita es reemplazada por una de su elección. [Desbordamiento del búfer] Utilizando el contenido del archivo especialmente manipulado, el adversario crea un enlace simbólico desde el recurso identificado hasta el archivo malicioso, provocando un ataque de desbordamiento del búfer dirigido.

Este tipo de ataque aprovecha el uso de etiquetas o variables de un dato de configuración formateado para provocar un desbordamiento del búfer. El adversario crea una página HTML maliciosa o un archivo de configuración que incluye cadenas sobredimensionadas, provocando así un desbordamiento. [Identificar la aplicación objetivo] El adversario identifica una aplicación o programa objetivo para realizar el desbordamiento del búfer. Los adversarios buscan aplicaciones o programas que acepten como entrada archivos formateados, como archivos de configuración. [Encontrar el vector de inyección] El adversario identifica un vector de inyección para enviar el contenido excesivo al búfer de la aplicación objetivo. [Elaborar el contenido de desbordamiento] El adversario elabora el contenido a inyectar. Si la intención es simplemente provocar la caída del software, el contenido sólo debe consistir en una cantidad excesiva de datos aleatorios. Si la intención es aprovechar el desbordamiento para la ejecución de código arbitrario, el adversario diseña la carga útil de tal manera que la dirección de retorno sobrescrita es reemplazada por una de su elección. [Desbordamiento del búfer] El adversario cargará el archivo manipulado en la aplicación, provocando un desbordamiento del búfer.

En este ataque, el software objetivo recibe una entrada que el adversario sabe que será modificada y ampliada en tamaño durante el procesamiento. Este ataque se basa en que el software objetivo no prevé que los datos expandidos puedan exceder algún límite interno, creando así un desbordamiento del búfer. [Identificar la aplicación objetivo] El adversario identifica una aplicación o programa objetivo para realizar el desbordamiento del búfer. Los adversarios suelen buscar aplicaciones que acepten entradas del usuario y que realicen una gestión manual de la memoria. [Encontrar el vector de inyección] El adversario identifica un vector de inyección para enviar el contenido excesivo al búfer de la aplicación objetivo. [El adversario elabora el contenido de desbordamiento que se dará al programa. Si la intención es simplemente hacer que el software se caiga, la entrada sólo necesita expandirse a una cantidad excesiva de datos aleatorios. Si la intención es aprovechar el desbordamiento para la ejecución de código arbitrario, el adversario elaborará una entrada que se expanda de manera que no sólo desborde el búfer objetivo, sino que lo haga de tal manera que la dirección de retorno sobrescrita sea reemplazada por una de su elección que apunte a un código inyectado por el adversario. [Desbordar el búfer] Utilizando el vector de inyección, el adversario da la entrada crafteada al programa, desbordando el búfer.

Un atacante genera un mensaje o un bloque de datos que hace creer al destinatario que el mensaje o el bloque de datos ha sido generado y firmado criptográficamente por una fuente autorizada o de buena reputación, engañando a la víctima o al sistema operativo de la víctima para que realice acciones maliciosas.

Un adversario incrusta uno o más bytes nulos en la entrada del software objetivo. Este ataque se basa en el uso de un byte nulo como terminador de cadena en muchos entornos. El objetivo es que ciertos componentes del software objetivo dejen de procesar la entrada cuando encuentren el o los bytes nulos. [Utilizando un navegador, una herramienta automatizada o inspeccionando la aplicación, un adversario registra todos los puntos de entrada a la aplicación. [El adversario utiliza los puntos de entrada recogidos en la fase de "Exploración" como una lista de objetivos e inyecta bytes nulos postfix para observar cómo la aplicación los maneja como entrada. El adversario busca áreas en las que la entrada del usuario se coloca en medio de una cadena, y el byte nulo hace que la aplicación deje de procesar la cadena al final de la entrada del usuario. [Eliminar los datos después del byte(s) nulo(s)] Después de determinar los puntos de entrada que son vulnerables, el adversario coloca un byte(s) nulo(s) de tal manera que elimina los datos después del byte(s) nulo(s) de una manera que le beneficia.

Si una cadena pasa por un filtro de algún tipo, entonces un NULL terminal puede no ser válido. El uso de una representación alternativa de NULL permite a un adversario incrustar el NULL en medio de la cadena mientras posfija los datos adecuados para evitar el filtro. Un ejemplo es un filtro que busca un carácter de barra al final. Si es posible insertar una cadena, pero la barra debe existir, se puede utilizar una codificación alternativa de NULL en medio de la cadena. [Inspeccionar la aplicación en busca de entradas controlables por el usuario] Utilizando un navegador, una herramienta automatizada o inspeccionando la aplicación, un adversario registra todos los puntos de entrada a la aplicación. [El adversario utiliza los puntos de entrada recogidos en la fase de "Exploración" como una lista de objetivos e inyecta byte(s) nulo(s) seguido(s) de una barra invertida para observar cómo la aplicación los maneja como entrada. El adversario busca áreas en las que la entrada del usuario se coloca en medio de una cadena, y el byte nulo hace que la aplicación deje de procesar la cadena al final de la entrada del usuario. [Después de determinar los puntos de entrada que son vulnerables, el adversario coloca un byte nulo seguido de una barra invertida de tal manera que se salta un filtro de entrada y elimina los datos después del byte nulo de una manera que le beneficia.

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.

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.

Este ataque se dirige a la codificación de la URL combinada con la codificación de los caracteres de barra. Un atacante puede aprovechar las múltiples formas de codificación de una URL y abusar de la interpretación de la misma. Una URL puede contener caracteres especiales que necesitan un manejo especial de la sintaxis para ser interpretados. Los caracteres especiales se representan mediante un carácter de porcentaje seguido de dos dígitos que representan el código de octetos del carácter original (%HEX-CODE). Por ejemplo, el carácter de espacio US-ASCII se representaría con %20. Esto se suele denominar terminación escapada o codificación porcentual. Dado que el servidor decodifica la URL a partir de las solicitudes, puede restringir el acceso a algunas rutas de URL validando y filtrando las solicitudes de URL que recibe. Un atacante intentará crear una URL con una secuencia de caracteres especiales que, una vez interpretada por el servidor, equivaldrá a una URL prohibida. Puede ser difícil protegerse contra este ataque ya que la URL puede contener otro formato de codificación como la codificación UTF-8, la codificación Unicode, etc. El atacante accede al servidor utilizando una URL específica. El atacante intenta codificar algunos caracteres especiales en la URL. El atacante descubre que algunos caracteres no se filtran correctamente. El atacante elabora una petición de cadena de URL maliciosa y la envía al servidor. El servidor decodifica e interpreta la cadena de URL. Desgraciadamente, como el filtrado de entrada no se hace correctamente, los caracteres especiales tienen consecuencias perjudiciales.

[Encontrar la aplicación objetivo] Encontrar la aplicación web objetivo que acepte una entrada de usuario y recupere datos del servidor [Examinar las solicitudes existentes de la aplicación] Examinar las solicitudes HTTP/GET para ver el formato de consulta de la URL. Los adversarios prueban si este tipo de ataque es posible a través de debilidades en la protección de una aplicación a la Falsificación de Solicitudes del Lado del Servidor [Solicitud maliciosa] El adversario elabora una solicitud de URL maliciosa que asume el nivel de privilegio del servidor para consultar servicios de red internos o externos y envía la solicitud a la aplicación

Este ataque se dirige a aplicaciones y software que utilizan la función syslog() de forma insegura. Si una aplicación no utiliza explícitamente un parámetro de cadena de formato en una llamada a syslog(), la entrada del usuario puede colocarse en el parámetro de cadena de formato, lo que lleva a un ataque de inyección de cadena de formato. Los adversarios pueden entonces inyectar comandos de cadena de formato maliciosos en la llamada a la función, provocando un desbordamiento del búfer. Hay muchas vulnerabilidades de software reportadas cuya causa principal es un mal uso de la función syslog(). [Identificar la aplicación objetivo] El adversario identifica una aplicación o programa objetivo para realizar el desbordamiento del búfer. En este ataque, los adversarios buscan aplicaciones que usen syslog() incorrectamente. [Encontrar el vector de inyección] El adversario identifica un vector de inyección para entregar el contenido excesivo al búfer de la aplicación objetivo. Para cada entrada controlable por el usuario que el adversario sospecha que es vulnerable a la inyección de cadenas de formato, intenta inyectar caracteres de formato como %n, %s, etc. El objetivo es manipular la creación de la cadena utilizando estos caracteres de formato. [El adversario elabora el contenido a inyectar. Si la intención es simplemente hacer que el software se caiga, el contenido sólo tiene que consistir en una cantidad excesiva de datos aleatorios. Si la intención es aprovechar el desbordamiento para la ejecución de código arbitrario, el adversario elaborará un conjunto de contenido que no sólo desborda el búfer objetivo, sino que lo hace de tal manera que la dirección de retorno sobrescrita se sustituye por una de su elección que apunta al código inyectado por el adversario. [Desbordamiento del búfer] Utilizando el vector de inyección, el adversario suministra al programa la inyección de la cadena de formato crafteada, provocando un desbordamiento del búfer.

La inyección SQL ciega es el resultado de una mitigación insuficiente de la inyección SQL. Aunque la supresión de los mensajes de error de la base de datos se considera la mejor práctica, la supresión por sí sola no es suficiente para prevenir la inyección SQL. La inyección SQL ciega es una forma de inyección SQL que supera la falta de mensajes de error. Sin los mensajes de error que facilitan la Inyección SQL, el adversario construye cadenas de entrada que sondean el objetivo a través de simples expresiones booleanas SQL. El adversario puede determinar si la sintaxis y la estructura de la inyección han tenido éxito en función de si la consulta se ha ejecutado o no. Aplicado de forma iterativa, el adversario determina cómo y dónde el objetivo es vulnerable a la inyección SQL. Determine cómo inyectar información en las consultas] [Determine la entrada controlable por el usuario susceptible de ser inyectada] Determine la entrada controlable por el usuario susceptible de ser inyectada. Para cada entrada controlable por el usuario que el adversario sospeche que es vulnerable a la inyección SQL, intente inyectar los valores determinados en el paso anterior. Si no se produce un error, el adversario sabe que la inyección SQL ha tenido éxito. Determina el tipo de base de datos] Determina el tipo de base de datos, como MS SQL Server u Oracle o MySQL, utilizando condiciones lógicas como parte de las consultas inyectadas [Extrae información sobre el esquema de la base de datos] Extrae información sobre el esquema de la base de datos haciendo que la base de datos responda a preguntas de sí/no sobre el esquema. Explotar la vulnerabilidad de inyección SQL] Utilizar la información obtenida en los pasos anteriores para inyectar con éxito la base de datos con el fin de eludir las comprobaciones o modificar, añadir, recuperar o eliminar datos de la base de datos.

Un atacante puede proporcionar una cadena Unicode a un componente del sistema que no es consciente de Unicode y utilizarla para eludir el filtro o hacer que el mecanismo de clasificación no comprenda correctamente la solicitud. Eso puede permitir al atacante deslizar datos maliciosos más allá del filtro de contenido y/o posiblemente hacer que la aplicación enrute la solicitud incorrectamente. [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 de 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 codificadas en Unicode para determinar si un punto de entrada representa realmente una vulnerabilidad con una lógica de validación insuficiente y para caracterizar hasta qué punto se puede explotar la vulnerabilidad.

Este ataque se dirige a la codificación de la URL. Un adversario puede aprovechar la forma múltiple de codificar una URL y abusar de la interpretación de la misma. [Inspeccionar la aplicación web en busca de URLs con parámetros] Utilizando un navegador, una herramienta automatizada o inspeccionando la aplicación, un adversario registra todas las URLs que contienen parámetros. [El adversario utiliza las URLs recopiladas en la fase de "Exploración" como una lista de objetivos y prueba los parámetros con diferentes codificaciones de caracteres especiales para ver cómo los maneja la aplicación web. [Inyectar caracteres especiales en los parámetros de la URL] Utilizando la información recopilada en la fase "Experimentar", el adversario inyecta caracteres especiales en la URL utilizando la codificación de la misma. Esto puede dar lugar a un recorrido de la ruta, a un scripting cruzado, a una inyección SQL, etc.

Un ataque de este tipo implica que un adversario inserte caracteres maliciosos (como una redirección XSS) en un nombre de archivo, directa o indirectamente que luego es utilizado por el software de destino para generar texto HTML u otro contenido potencialmente ejecutable. Muchos sitios web se basan en contenidos generados por el usuario y construyen dinámicamente recursos como archivos, nombres de archivos y enlaces URL directamente a partir de los datos suministrados por el usuario. En este patrón de ataque, el atacante carga código que puede ejecutarse en el navegador del cliente y/o redirigir el navegador del cliente a un sitio que el atacante posee. Todas las variantes de carga útil de los ataques XSS pueden utilizarse para pasar y explotar estas vulnerabilidades.

Este ataque se dirige al uso de la barra invertida en la codificación alternativa. Un adversario puede proporcionar una barra invertida como carácter inicial y hacer que el analizador sintáctico crea que el siguiente carácter es especial. Esto se llama un escape. Usando ese truco, el adversario intenta explotar formas alternativas de codificar el mismo carácter, lo que conduce a problemas de filtrado y abre vías de ataque. [Inspeccionar la aplicación en busca de entradas controlables por el usuario] Utilizando un navegador, una herramienta automatizada o inspeccionando la aplicación, un adversario registra todos los puntos de entrada a la aplicación. [El adversario utiliza los puntos de entrada recogidos en la fase de "Exploración" como una lista de objetivos e intenta escapar de varios caracteres especiales diferentes utilizando una barra invertida. [Manipular la entrada] Una vez que el adversario determina cómo eludir los filtros que filtran los caracteres especiales utilizando una barra invertida, manipulará la entrada del usuario de una manera no prevista por la aplicación.

Este ataque se dirige a la codificación de los caracteres de la barra diagonal. Un adversario trataría de explotar los problemas de filtrado comunes relacionados con el uso de los caracteres de barra para obtener acceso a los recursos en el host objetivo. Los sistemas basados en directorios, como los sistemas de archivos y las bases de datos, suelen utilizar el carácter de barra para indicar el paso entre directorios u otros componentes del contenedor. Por turbias razones históricas, los PC (y, en consecuencia, los SO de Microsoft) optan por utilizar una barra invertida, mientras que el mundo UNIX suele hacer uso de la barra diagonal. El resultado esquizofrénico es que muchos sistemas basados en MS deben entender ambas formas de la barra. Esto da al adversario muchas oportunidades para descubrir y abusar de una serie de problemas de filtrado comunes. El objetivo de este patrón es descubrir el software del servidor que sólo aplica filtros a una versión, pero no a la otra. [Inspeccionar la aplicación en busca de entradas controlables por el usuario] Utilizando un navegador, una herramienta automatizada o inspeccionando la aplicación, un adversario registra todos los puntos de entrada a la aplicación. [El adversario utiliza los puntos de entrada recogidos en la fase de "exploración" como una lista de objetivos y busca las áreas en las que la entrada del usuario se utiliza para acceder a los recursos en el host de destino. El adversario intenta diferentes codificaciones de caracteres de barra para evitar los filtros de entrada. [Una vez que el adversario determina cómo eludir los filtros que filtran los caracteres de barra, manipulará la entrada del usuario para incluir barras con el fin de atravesar los directorios y acceder a los recursos que no están destinados al usuario.

Este ataque se dirige a bibliotecas o módulos de código compartido que son vulnerables a los ataques de desbordamiento de búfer. Un adversario que tenga conocimiento de las bibliotecas o el código compartido vulnerables conocidos puede atacar fácilmente el software que hace uso de estas bibliotecas. Todos los clientes que hacen uso de la biblioteca de código se vuelven así vulnerables por asociación. Esto tiene un efecto muy amplio en la seguridad de un sistema, que suele afectar a más de un proceso de software. [Identificar la aplicación objetivo] El adversario, con conocimiento de las bibliotecas o módulos de código compartido vulnerables, identifica una aplicación o programa objetivo que hace uso de ellos. [Encontrar el vector de inyección] El adversario intenta utilizar la API y, si puede, envía una gran cantidad de datos para ver si el ataque de desbordamiento del búfer realmente funciona. [El adversario elabora el contenido a inyectar basándose en su conocimiento de la vulnerabilidad y el resultado deseado. Si la intención es simplemente hacer que el software se bloquee, el contenido sólo tiene que consistir en una cantidad excesiva de datos aleatorios. Si la intención es aprovechar el desbordamiento para la ejecución de código arbitrario, el adversario elaborará un conjunto de contenido que no sólo desborde el búfer objetivo, sino que lo haga de tal manera que la dirección de retorno sobrescrita sea reemplazada por una de su elección que apunte al código inyectado por el adversario. [Desbordamiento del búfer] Utilizando la API como vector de inyección, el adversario inyecta el contenido de desbordamiento elaborado en el búfer.

Este ataque es una variación específica del aprovechamiento de codificaciones alternativas para eludir la lógica de validación. Este ataque aprovecha la posibilidad de codificar entradas potencialmente dañinas en UTF-8 y enviarlas a aplicaciones que no esperan o no son efectivas para validar este estándar de codificación, dificultando el filtrado de entradas. UTF-8 (8-bit UCS/Unicode Transformation Format) es una codificación de caracteres de longitud variable para Unicode. Los caracteres UTF-8 legales tienen entre uno y cuatro bytes de longitud. Sin embargo, la primera versión de la especificación UTF-8 se equivocó en algunas entradas (en algunos casos permitía caracteres demasiado largos). Se supone que los codificadores de UTF-8 deben utilizar la codificación "más corta posible", pero los descodificadores ingenuos pueden aceptar codificaciones más largas de lo necesario. Según el RFC 3629, una forma particularmente sutil de este ataque puede llevarse a cabo contra un analizador sintáctico que realice comprobaciones de validez críticas para la seguridad contra la forma codificada en UTF-8 de su entrada, pero que interprete ciertas secuencias de octetos ilegales como caracteres. [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 de 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 codificadas en UTF-8 para determinar si un punto de entrada representa realmente una vulnerabilidad con una lógica de validación insuficiente y para caracterizar hasta qué punto se puede explotar la vulnerabilidad.

Los ataques de manipulación de registros web implican que un atacante inyecte, borre o manipule de alguna manera el contenido de los registros web, normalmente con el fin de enmascarar otro comportamiento malicioso. Además, la escritura de datos maliciosos en los archivos de registro puede tener como objetivo trabajos, filtros, informes y otros agentes que procesan los registros en un patrón de ataque asíncrono. Este patrón de ataque es similar al de "Log Injection-Tampering-Forging", excepto que en este caso, el ataque se dirige a los registros del servidor web y no a la aplicación. [El atacante observa el sistema y busca indicadores de qué utilidad de registro está utilizando el servidor web. [Determinar el contenido inyectable] El atacante lanza varias acciones registradas con datos maliciosos para determinar qué tipo de inyección de registro es posible. [Manipular los archivos de registro] El atacante altera el contenido del registro, ya sea directamente a través de la manipulación o la falsificación, o indirectamente a través de la inyección de una solicitud especialmente diseñada que el servidor web recibirá y escribirá en los registros. Este tipo de ataque suele seguir a otro y se utiliza para intentar cubrir los rastros del ataque anterior.

Un atacante puede crear una entrada especial controlable por el usuario que consista en expresiones XPath para inyectar la base de datos XML y saltarse la autenticación o recoger información que normalmente no podría. La inyección XPath permite a un atacante hablar directamente con la base de datos XML, evitando así la aplicación por completo. La inyección de XPath es el resultado de la incapacidad de una aplicación para sanear adecuadamente la entrada utilizada como parte de las expresiones dinámicas XPath utilizadas para consultar una base de datos XML. [Utilizando un navegador o una herramienta automatizada, un adversario registra todas las instancias de entrada controlables por el usuario utilizadas para construir consultas XPath. [Determinar la estructura de las consultas] Utilizando medios manuales o automatizados, probar las entradas encontradas para detectar las debilidades de XPath. [Inyectar contenido en la consulta XPath] Crear contenido malicioso que contenga expresiones XPath que no sean validadas por la aplicación y que se ejecuten como parte de las consultas XPath.

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.

En este tipo de ataque, un adversario inyecta comandos del sistema operativo en las funciones de las aplicaciones existentes. Una aplicación que utiliza entradas no confiables para construir cadenas de comandos es vulnerable. Un adversario puede aprovechar la inyección de comandos del sistema operativo en una aplicación para elevar los privilegios, ejecutar comandos arbitrarios y comprometer el sistema operativo subyacente. Identificar las entradas para los comandos del sistema operativo] El atacante determina las entradas controlables por el usuario que se pasan como parte de un comando al sistema operativo subyacente. El atacante examina la aplicación objetivo, posiblemente como un usuario válido y autenticado [Variar las entradas, buscando resultados maliciosos] Dependiendo de si la aplicación que está siendo explotada es remota o local, el atacante elabora la entrada maliciosa apropiada, que contiene comandos del sistema operativo, para ser pasada a la aplicación [Ejecutar comandos maliciosos] El atacante puede robar información, instalar un mecanismo de acceso de puerta trasera, elevar los privilegios o comprometer el sistema de alguna otra manera.

Este ataque se dirige a las utilidades de línea de comandos disponibles en una serie de shells. Un adversario puede aprovechar una vulnerabilidad encontrada en una utilidad de línea de comandos para elevar los privilegios a root. [Identificar el sistema objetivo] El adversario primero encuentra un sistema objetivo en el que quiere obtener privilegios elevados. Puede tratarse de un sistema al que ya tiene algún nivel de acceso o de un sistema al que obtendrá acceso no autorizado con un privilegio inferior utilizando algún otro medio. [El adversario identifica las utilidades de línea de comandos expuestas por el host objetivo que contienen vulnerabilidades de desbordamiento de búfer. El adversario probablemente sabe qué utilidades tienen estas vulnerabilidades y cuáles son las versiones afectadas, por lo que también obtendrá los números de versión de estas utilidades. [Una vez que el adversario ha encontrado una utilidad vulnerable, utilizará su conocimiento de la vulnerabilidad para crear el comando que explotará el desbordamiento del búfer. [Desbordamiento del búfer] Utilizando el vector de inyección, el adversario ejecuta el comando creado, obteniendo privilegios elevados en la máquina.