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 las razones que sean.
En los primeros días de Internet, uno de los métodos de ataque más comunes era básico, simple la fuerza bruta. Por lo general, los bots realizaban estos ataques, o personas con mucho tiempo libre, que probaban millones de combinaciones de nombres de usuario y contraseñas hasta que encontraron una que les otorgaría acceso 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. De esa forma entraron en escena los llamados ataques por 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 sensible, o incluso para secuestrar un servidor completo. Es por eso que estos ataques no son solo un amenaza para las aplicaciones web, sino también a los usuarios cuyos datos residen en esas aplicaciones y, en el peor de los casos, a otras aplicaciones y servicios conectados.
Code injection
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 sea posible la entrada a los usuarios.
Por ejemplo, debe 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 aprovechar una de estas vulnerabilidades, el impacto podría incluir la pérdida de confidencialidad, integridad, disponibilidad o funcionalidad de la aplicación.
SQL injection
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 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 SQL, y se pueden encontrar fácilmente, 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 indudablemente alto.
Command injection
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 scripts. 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 conocer el sistema operativo que utiliza el servidor de alojamiento.
Los comandos del sistema insertados son ejecutados por el sistema operativo host con el privilegios de la aplicación, que podría permitir exponer el contenido de archivos arbitrarios que residen en el servidor, mostrar la estructura de directorios de un servidor, cambiar las contraseñas de los usuarios, 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.
Cross-site scripting
Siempre que una aplicación inserta la entrada de un usuario dentro de la salida que genera, sin validarla o codificarla, le da la oportunidad a un atacante de enviar código malicioso a un usuario final diferente. Los ataques de Cross-Site Scripting (XSS) aprovechan estas oportunidades para inyectar scripts maliciosos en sitios web de confianza, 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 en él. Por lo tanto, el navegador le permitirá acceder a tokens de sesión, cookies o información confidencial almacenada por el navegador. Si se programan correctamente, los scripts podrían incluso reescribir el contenido de un archivo HTML.
Los ataques XSS se pueden dividir generalmente en dos categorías diferentes: almacenados y reflejados.
In almacenados Ataques XSS, 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 refleja Ataques XSS, 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.
XPath injection
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 inyección 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, como SQL, puedes especificar los atributos que deseas buscar. Para realizar una consulta en datos XML, las aplicaciones web utilizan 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 quiere aplicar a los datos.
A diferencia de lo que ocurre con SQL, en XPath no existen versiones diferentes. Esto significa que la inyección 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 dispararse contra un número arbitrario de objetivos.
Mail command injection
Este método de ataque se puede utilizar para explotar los servidores de correo electrónico y las aplicaciones que crean IMAP o SMTP declaraciones con entrada de usuario validada incorrectamente. Ocasionalmente, los servidores IMAP y SMTP no tienen una protección sólida contra los ataques, como sería el caso con la mayoría de los servidores web, y por lo tanto podrían ser más explotables. Al ingresar 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, permitiéndoles, 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.
CRLF injection
La inserción de caracteres de retorno de carro y salto de línea –combinación conocida como CRLF– en los campos de entrada del formulario web representa un método de ataque llamado inyección CRLF. Estos caracteres invisibles indican el final de una línea o el final de un comando en muchos protocolos tradicionales de Internet, como HTTP, MIME o NNTP.
Por ejemplo, la inserción de una 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 otros tipos 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.
Host Header injection
En los servidores que albergan 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 utilizar para enviar encabezados de host arbitrarios al primer host virtual en un servidor.
La manipulación del encabezado del host está comúnmente relacionada con aplicaciones PHP, aunque también se puede hacer 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 la caché web. Sus consecuencias podrían incluir la ejecución de operaciones sensibles por parte de los atacantes, por ejemplo, restablecimiento de contraseñas.
LDAP injection
LDAP es un protocolo diseñado para facilitar la búsqueda de recursos (dispositivos, archivos, otros usuarios) en una red. Es muy útil para las 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 raíz que permite los ataques de inyección LDAP es la entrada del usuario mal validada. Si el texto que un usuario envía a una aplicación se usa como parte de una consulta LDAP sin desinfectarla, la consulta podría terminar recuperando una lista de todos los usuarios y mostrándola a un atacante, simplemente usando un asterisco (*) en la parte derecha. colocar dentro de una cadena de entrada.
Prevención de ataques por 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.
Los desarrolladores de aplicaciones necesitan conocer los riesgos involucrados en la validación incorrecta de la entrada del usuario y aprender las mejores prácticas para desinfectar la entrada del usuario con fines de prevención de riesgos. Los administradores de servidores necesitan auditar sus sistemas periódicamente para detectar vulnerabilidades y corríjalos lo antes posible. Hay muchas opciones para realizar estas auditorías, ya sea a pedido o automáticamente.
