9 tipos populares de ataques de inyección de aplicaciones web

El problema con las aplicaciones web es que están expuestas abiertamente a miles de millones de usuarios de Internet, muchos de los cuales querrán romper sus medidas de seguridad, por cualquier motivo.

En los primeros días de Internet, uno de los métodos de ataque más comunes era la fuerza bruta simple y básica. Los bots solían realizar estos ataques, o personas con mucho tiempo libre, que probaban millones de combinaciones de nombres de usuario y contraseñas hasta encontrar una que les permitiera acceder a la aplicación de destino.

Los ataques de fuerza bruta ya no son una amenaza gracias a las políticas de contraseñas, intentos de inicio de sesión limitados y captchas. Pero a los ciberdelincuentes les encanta descubrir nuevos exploits y usarlos para realizar nuevos tipos de ataques. Hace mucho tiempo, descubrieron que los campos de texto en aplicaciones o páginas web podían explotarse ingresando, o inyectando, texto inesperado en ellos que obligaría a la aplicación a hacer algo que se suponía que no debía hacer. Así entraron en escena los llamados ataques de inyección.

Los ataques de inyección se pueden usar no solo para iniciar sesión en una aplicación sin conocer el nombre de usuario y la contraseña, sino también para exponer información privada, confidencial o confidencial, o incluso para secuestrar un servidor completo. Es por eso que estos ataques no solo son una amenaza para las aplicaciones web, sino también para los usuarios cuyos datos residen en esas aplicaciones y, en el peor de los casos, para otras aplicaciones y servicios conectados.

Inyección de código

La inyección de código es uno de los tipos más comunes de ataques de inyección. Si los atacantes conocen el lenguaje de programación, el marco, la base de datos o el sistema operativo utilizado por una aplicación web, pueden inyectar código a través de campos de entrada de texto para obligar al servidor web a hacer lo que quieran.

Estos tipos de ataques de inyección son posibles en aplicaciones que carecen de validación de datos de entrada. Si un campo de entrada de texto permite a los usuarios ingresar lo que quieran, entonces la aplicación es potencialmente explotable. Para evitar estos ataques, la aplicación debe restringir tanto como pueda las entradas que los usuarios pueden ingresar.

Por ejemplo, necesita limitar la cantidad de datos esperados, verificar el formato de los datos antes de aceptarlos y restringir el conjunto de caracteres permitidos.

Las vulnerabilidades de inyección de código pueden ser fáciles de encontrar, simplemente probando la entrada de texto de una aplicación web con diferentes tipos de contenido. Cuando se encuentran, las vulnerabilidades son moderadamente difíciles de explotar. Pero cuando un atacante logra explotar una de estas vulnerabilidades, el impacto podría incluir la pérdida de confidencialidad, integridad, disponibilidad o funcionalidad de la aplicación.

inyección SQL

De manera similar a la inyección de código, este ataque inserta un script SQL, el lenguaje utilizado por la mayoría de las bases de datos para realizar operaciones de consulta, en un campo de entrada de texto. El script se envía a la aplicación, que lo ejecuta directamente en su base de datos. Como resultado, el atacante podría atravesar una pantalla de inicio de sesión o hacer cosas más peligrosas, como leer datos confidenciales directamente de la base de datos, modificar o destruir datos de la base de datos o ejecutar operaciones de administración en la base de datos.

Las aplicaciones PHP y ASP son propensas a los ataques de inyección SQL debido a sus interfaces funcionales más antiguas. Las aplicaciones J2EE y ASP.Net suelen estar más protegidas contra estos ataques. Cuando se encuentra una vulnerabilidad de inyección de código SQL, que podría ser fácil de encontrar, la magnitud de los ataques potenciales solo estará limitada por la habilidad y la imaginación del atacante. Por lo tanto, el impacto de un ataque de inyección SQL es sin duda alto.

Inyección de comandos

Estos ataques también son posibles, principalmente debido a una validación de entrada insuficiente. Se diferencian de los ataques de inyección de código en que el atacante inserta comandos del sistema en lugar de fragmentos de código de programación o secuencias de comandos. Por lo tanto, el hacker no necesita conocer el lenguaje de programación en el que se basa la aplicación o el lenguaje utilizado por la base de datos. Pero necesitan saber el sistema operativo utilizado por el servidor de alojamiento.

Los comandos del sistema insertados son ejecutados por el sistema operativo host con los privilegios de la aplicación, lo que podría permitir exponer el contenido de archivos arbitrarios que residen en el servidor, mostrar la estructura de directorios de un servidor, cambiar contraseñas de usuario, entre otras cosas. .

Un administrador de sistemas puede prevenir estos ataques limitando el nivel de acceso al sistema de las aplicaciones web que se ejecutan en un servidor.

Secuencias de comandos entre sitios

Cada vez que una aplicación inserta la entrada de un usuario dentro de la salida que genera, sin validarla ni codificarla, le da la oportunidad a un atacante de enviar código malicioso a un usuario final diferente. Los ataques Cross-Site Scripting (XSS) aprovechan estas oportunidades para inyectar scripts maliciosos en sitios web confiables, que finalmente se envían a otros usuarios de la aplicación, que se convierten en víctimas del atacante.

El navegador de las víctimas ejecutará el script malicioso sin saber que no se debe confiar. Por lo tanto, el navegador le permitirá acceder a tokens de sesión, cookies o información confidencial almacenada por el navegador. Si se programa correctamente, los scripts podrían incluso reescribir el contenido de un archivo HTML.

Los ataques XSS generalmente se pueden dividir en dos categorías diferentes: almacenados y reflejados.

En los ataques XSS almacenados, el script malicioso reside permanentemente en el servidor de destino, en un foro de mensajes, en una base de datos, en un registro de visitantes, etc. La víctima lo obtiene cuando su navegador solicita la información almacenada. En los ataques XSS reflejados, el script malicioso se refleja en una respuesta que incluye la entrada enviada al servidor. Esto podría ser un mensaje de error o un resultado de búsqueda, por ejemplo.

Inyección XPath

Este tipo de ataque es posible cuando una aplicación web utiliza información proporcionada por un usuario para crear una consulta XPath para datos XML. La forma en que funcionan estos ataques es similar a la inyección de SQL: los atacantes envían información mal formada a la aplicación para averiguar cómo están estructurados los datos XML y luego atacan nuevamente para acceder a esos datos.

XPath es un lenguaje estándar con el que, al igual que SQL, puede especificar los atributos que desea encontrar. Para realizar una consulta en datos XML, las aplicaciones web usan la entrada del usuario para establecer un patrón que los datos deben coincidir. Al enviar una entrada con formato incorrecto, el patrón puede convertirse en una operación que el atacante desea aplicar a los datos.

A diferencia de lo que sucede con SQL, en XPath no existen diferentes versiones. Esto significa que la inyección de XPath se puede realizar en cualquier aplicación web que utilice datos XML, independientemente de la implementación. Eso también significa que el ataque se puede automatizar; por lo tanto, a diferencia de la inyección SQL, tiene el potencial de ser disparado contra un número arbitrario de objetivos.

Inyección de comandos de correo

Este método de ataque se puede utilizar para explotar servidores de correo electrónico y aplicaciones que crean declaraciones IMAP o SMTP con entradas de usuario validadas incorrectamente. Ocasionalmente, los servidores IMAP y SMTP no tienen una fuerte protección contra ataques, como sería el caso de la mayoría de los servidores web, y por lo tanto podrían ser más explotables. Entrando a través de un servidor de correo, los atacantes podrían evadir restricciones como captchas, un número limitado de solicitudes, etc.

Para explotar un servidor SMTP, los atacantes necesitan una cuenta de correo electrónico válida para enviar mensajes con comandos inyectados. Si el servidor es vulnerable, responderá a las solicitudes de los atacantes, lo que les permitirá, por ejemplo, anular las restricciones del servidor y utilizar sus servicios para enviar spam.

La inyección de IMAP podría realizarse principalmente en aplicaciones de correo web, aprovechando la funcionalidad de lectura de mensajes. En estos casos, el ataque se puede realizar simplemente ingresando, en la barra de direcciones de un navegador web, una URL con los comandos inyectados.

Inyección CRLF

La inserción de caracteres de retorno de carro y avance de línea –combinación conocida como CRLF– en los campos de entrada de formularios web representa un método de ataque llamado inyección de CRLF. Estos caracteres invisibles indican el final de una línea o el final de un comando en muchos protocolos de Internet tradicionales, como HTTP, MIME o NNTP.

Por ejemplo, la inserción de un CRLF en una solicitud HTTP, seguida de cierto código HTML, podría enviar páginas web personalizadas a los visitantes de un sitio web.

Este ataque se puede realizar en aplicaciones web vulnerables que no aplican el filtrado adecuado a la entrada del usuario. Esta vulnerabilidad abre la puerta a otro tipo de ataques de inyección, como XSS e inyección de código, y también podría derivar en el secuestro de un sitio web.

Inyección de encabezado de host

En los servidores que alojan muchos sitios web o aplicaciones web, el encabezado del host se vuelve necesario para determinar cuál de los sitios web o aplicaciones web residentes (cada uno de ellos conocido como host virtual) debe procesar una solicitud entrante. El valor del encabezado le dice al servidor a cuál de los hosts virtuales enviar una solicitud. Cuando el servidor recibe un encabezado de host no válido, generalmente lo pasa al primer host virtual de la lista. Esto constituye una vulnerabilidad que los atacantes pueden usar para enviar encabezados de host arbitrarios al primer host virtual en un servidor.

La manipulación del encabezado del host suele estar relacionada con las aplicaciones PHP, aunque también se puede realizar con otras tecnologías de desarrollo web. Los ataques de encabezado de host funcionan como habilitadores para otros tipos de ataques, como el envenenamiento de caché web. Sus consecuencias podrían incluir la ejecución de operaciones sensibles por parte de los atacantes, por ejemplo, restablecimientos de contraseñas.

inyección LDAP

LDAP es un protocolo diseñado para facilitar la búsqueda de recursos (dispositivos, archivos, otros usuarios) en una red. Es muy útil para intranets y, cuando se usa como parte de un sistema de inicio de sesión único, se puede usar para almacenar nombres de usuario y contraseñas. Las consultas LDAP implican el uso de caracteres de control especiales que afectan su control. Los atacantes pueden cambiar potencialmente el comportamiento previsto de una consulta LDAP si pueden insertar caracteres de control en ella.

Una vez más, el problema principal que permite los ataques de inyección de LDAP es la entrada del usuario validada incorrectamente. Si el texto que un usuario envía a una aplicación se usa como parte de una consulta LDAP sin desinfectarlo, la consulta podría terminar recuperando una lista de todos los usuarios y mostrársela a un atacante, simplemente usando un asterisco.

en el lugar correcto dentro de una cadena de entrada.

Prevención de ataques de inyección

Como vimos en este artículo, todos los ataques de inyección están dirigidos a servidores y aplicaciones con acceso abierto a cualquier usuario de Internet. La responsabilidad de prevenir estos ataques se distribuye entre los desarrolladores de aplicaciones y los administradores de servidores.