El problema de las aplicaciones web es que están expuestas abiertamente a miles de millones de internautas, muchos de los cuales querrán saltarse 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 la fuerza bruta básica y simple. Normalmente, estos ataques los realizaban bots –o personas con mucho tiempo libre– que probaban trillones de combinaciones de nombres de usuario y contraseñas hasta encontrar una que les permitiera acceder a la aplicación objetivo.
Los ataques de fuerza bruta ya no son una amenaza, gracias a las políticas de contraseñas, los intentos limitados de inicio de sesión y los captchas. Pero a los ciberdelincuentes les encanta descubrir nuevos exploits y utilizarlos para realizar nuevos tipos de ataques. Hace mucho tiempo, descubrieron que los campos de texto de las aplicaciones o páginas web podían explotarse introduciendo –o inyectando– un texto inesperado en ellos que forzara a la aplicación a hacer algo que se suponía que no debía hacer. De ese modo, entraron en escena los llamados ataques por inyección.
Los ataques de inyección pueden utilizarse no sólo para entrar 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 todo un servidor. Por eso, estos ataques no sólo 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 de trabajo, la base de datos o el sistema operativo que utiliza una aplicación web, pueden inyectar código a través de los campos de entrada de texto para obligar al servidor web a hacer lo que ellos quieren.
Este tipo 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 introducir lo que quieran, entonces la aplicación es potencialmente explotable. Para evitar estos ataques, la aplicación debe restringir todo lo que pueda la entrada que los usuarios pueden introducir.
Por ejemplo, necesita limitar la cantidad de datos esperados, comprobar 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 consigue 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 forma 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 pasar a través de una pantalla de inicio de sesión o hacer cosas más peligrosas, como leer datos sensibles 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 SQL –y podrían encontrarse fácilmente– la magnitud de los ataques potenciales sólo 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.
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 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 sí necesitan conocer el sistema operativo utilizado por el servidor de alojamiento.
Los comandos del sistema insertados son ejecutados por el sistema operativo anfitrión 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 las contraseñas de los usuarios, entre otras cosas.
Estos ataques pueden ser prevenidos por un administrador del sistema, 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 ni codificarla, da la oportunidad a un atacante de enviar código malicioso a un usuario final diferente. Los ataques de secuencias de comandos en sitios cruzados (XSS) aprovechan estas oportunidades para inyectar secuencias de comandos maliciosas en sitios web de confianza, que en última instancia se envían a otros usuarios de la aplicación, que se convierten en las víctimas del atacante.
El navegador de las víctimas ejecutará el script malicioso sin saber que no es de confianza. Por lo tanto, el navegador le permitirá acceder a testigos de sesión, cookies o información sensible almacenada por el navegador. Si se programan adecuadamente, los scripts podrían incluso reescribir el contenido de un archivo HTML.
Los ataques XSS pueden dividirse generalmente en dos categorías diferentes: almacenados y reflejados.
En los ataques XSS almacenados, el script malicioso reside permanentemente en el servidor objetivo, en un foro de mensajes, en una base de datos, en un registro de visitas, etc. La víctima lo recibe 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. Puede ser un mensaje de error o el resultado de una búsqueda, por ejemplo.
Inyección XPath
Este tipo de ataque es posible cuando una aplicación web utiliza la información proporcionada por un usuario para construir una consulta XPath de datos XML. La forma en que funciona este ataque es similar a la inyección SQL: los atacantes envían información malformada a la aplicación para averiguar cómo están estructurados los datos XML, y luego vuelven a atacar 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 sobre datos XML, las aplicaciones web utilizan la entrada del usuario para establecer un patrón con el que deben coincidir los datos. Al enviar una entrada malformada, el patrón puede convertirse en una operación que el atacante quiera 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 puede realizarse en cualquier aplicación web que utilice datos XML, independientemente de la implementación. Eso también significa que el ataque puede automatizarse; por lo tanto, a diferencia de la inyección SQL, tiene el potencial de dispararse contra un número arbitrario de objetivos.
Inyección de comandos de correo
Este método de ataque puede utilizarse para explotar servidores de correo electrónico y aplicaciones que construyen sentencias IMAP o SMTP con entradas de usuario incorrectamente validadas. En ocasiones, los servidores IMAP y SMTP no cuentan con una fuerte protección contra los 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 peticiones, etc.
Para explotar un servidor SMTP, los atacantes necesitan una cuenta de correo válida para enviar mensajes con comandos inyectados. Si el servidor es vulnerable, responderá a las peticiones de los atacantes, permitiéndoles, por ejemplo, anular las restricciones del servidor y utilizar sus servicios para enviar spam.
La inyección IMAP podría realizarse principalmente en aplicaciones de correo web, explotando la funcionalidad de lectura de mensajes. En estos casos, el ataque puede realizarse simplemente introduciendo, 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 denominado 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 un CRLF en una petición HTTP, seguida de cierto código HTML, podría enviar páginas web personalizadas a los visitantes de un sitio web.
Este ataque puede realizarse en aplicaciones web vulnerables que no apliquen 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.
Inyección del encabezado del host
En los servidores que alojan muchos sitios web o aplicaciones web, la cabecera host se hace necesaria 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 de la cabecera indica al servidor a cuál de los hosts virtuales debe enviar una solicitud. Cuando el servidor recibe una cabecera de host no válida, suele pasarla al primer host virtual de la lista. Esto constituye una vulnerabilidad que los atacantes pueden utilizar para enviar cabeceras de host arbitrarias al primer host virtual de un servidor.
La manipulación de la cabecera del host está comúnmente relacionada con las aplicaciones PHP, aunque también puede realizarse con otras tecnologías de desarrollo web. Los ataques a la cabecera del host funcionan como facilitadores de 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, el restablecimiento 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 las intranets y, cuando se utiliza como parte de un sistema de inicio de sesión único, puede servir para almacenar nombres de usuario y contraseñas. Las consultas LDAP implican el uso de caracteres de control especiales que afectan a su control. Los atacantes pueden cambiar potencialmente el comportamiento previsto de una consulta LDAP si consiguen insertar caracteres de control en ella.
Una vez más, el problema de fondo que permite los ataques de inyección LDAP es la entrada de usuario incorrectamente validada. Si el texto que un usuario envía a una aplicación se utiliza como parte de una consulta LDAP sin higienizarlo, la consulta podría acabar recuperando una lista de todos los usuarios y mostrándosela a un atacante, simplemente utilizando un asterisco (*) en el lugar adecuado dentro de una cadena de entrada.
Prevención de ataques de inyección
Como hemos visto en este artículo, todos los ataques de inyección se dirigen a servidores y aplicaciones con acceso abierto a cualquier usuario de Internet. La responsabilidad de prevenir estos ataques se reparte entre los desarrolladores de las aplicaciones y los administradores de los servidores.
Los desarrolladores de aplicaciones necesitan conocer los riesgos que conlleva la validación incorrecta de la entrada del usuario y aprender las mejores prácticas para sanear 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 corregirlas lo antes posible. Existen muchas opciones para realizar estas auditorías, ya sea bajo demanda o de forma automática.