Programadores que conquistan la seguridad: Serie Compartir y Aprender - Inyecciones XML

Los ataques de inyección XML son exploits malintencionados creados por hackers para comprometer sistemas que alojan bases de datos XML. Esto incluye todo lo que asociamos con las bases de datos tradicionales: depósitos detallados de información que van desde medicamentos hasta películas. Algunos almacenes de datos XML también se utilizan para verificar usuarios autorizados, por lo que inyectar nuevo código XML en ellos puede crear usuarios nuevos que el sistema anfitrión aceptará a partir de ese momento.

Para que un atacante pueda implementar una inyección XML, debe existir una aplicación que dependa de, o al menos acceda a, una base de datos XML. Siempre que esto ocurra y la entrada del usuario no se valide correctamente, se puede añadir nuevo código XML al almacén de datos. Dependiendo de la habilidad del atacante, añadir nuevo código XML puede causar daños considerables o incluso proporcionar acceso a toda la base de datos.

A medida que sigas leyendo, descubrirás que la inyección XML está estrechamente relacionada con los ataques de inyección SQL que tratamos anteriormente. Esto se debe a que, aunque se dirigen a diferentes tipos de bases de datos, son extremadamente similares. Afortunadamente, las soluciones también lo son. Aprender a derrotar un tipo de ataque te dará una gran ventaja a la hora de prevenir el otro.

En este episodio, aprenderemos:

• Cómo funcionan las inyecciones XML
• Por qué son tan peligrosas
• Cómo puedes implementar defensas para detenerlas por completo.

¿Cómo ejecutan los atacantes las inyecciones XML?

Las inyecciones XML tienen éxito siempre que un usuario no autorizado pueda escribir código XML e insertarlo en una base de datos XML existente. Para que esto funcione solo se requieren dos cosas: una aplicación que dependa de, o se conecte a, una base de datos XML y una ruta de datos sin asegurar para que el atacante lance su ataque.

Las inyecciones XML casi siempre tienen éxito si la entrada del usuario no se desinfecta o se restringe antes de enviarse al servidor para su procesamiento. Esto permite a los atacantes escribir su propio código, o inyectarlo, al final de su cadena de consulta normal. Si tienen éxito, engañan al servidor para que ejecute el código XML, lo que le permite añadir o eliminar registros, o incluso revelar una base de datos completa.

Los hackers implementan un ataque de inyección XML añadiendo código XML a una consulta normal. Esto puede ser cualquier cosa, desde un campo de búsqueda hasta una página de inicio de sesión. Incluso puede incluir elementos como cookies o encabezados.

Por ejemplo, en un formulario de registro, un usuario podría añadir el siguiente código después del campo de nombre de usuario o contraseña:

<user></user>
<role>administrator</role>
<username>John_Smith</username><password>Jump783!Tango@12</password>

En este ejemplo, se crearía un nuevo usuario llamado John_Smith con acceso de administrador. Al menos el nuevo usuario utiliza reglas de densidad de contraseña adecuadas. Lástima que en realidad sea un atacante.

Los hackers no siempre necesitan lograr un éxito rotundo para triunfar con las inyecciones XML. Al manipular sus consultas y registrar los diversos mensajes de error que devuelve el servidor, pueden llegar a mapear la estructura de la base de datos XML. Y esa información puede utilizarse para mejorar otros tipos de ataques.

¿Por qué son tan peligrosas las inyecciones XML?

El nivel de peligro que conlleva un ataque de inyección XML depende de la información almacenada en la base de datos XML objetivo o de cómo se utilice dicha información. Por ejemplo, en el caso de una base de datos XML utilizada para autenticar usuarios, una inyección XML puede dar a un atacante acceso al sistema. Incluso podría permitirle convertirse en administrador de la red objetivo, lo cual es, por supuesto, una situación extremadamente peligrosa.

Para las inyecciones XML dirigidas a bases de datos más tradicionales, el peligro reside en el robo de información, la adición de datos incorrectos al almacén o, posiblemente, la sobrescritura de datos válidos. El código XML no es muy difícil de aprender y algunos de los comandos pueden ser extremadamente potentes, sobrescribiendo campos de información completos o incluso mostrando el contenido de un almacén de datos.

Por lo general, nadie construye una base de datos a menos que la información almacenada en ella tenga valor. Los hackers lo saben, por eso suelen ser su objetivo. Si esos datos incluyen información personal de empleados o clientes, su compromiso puede provocar pérdida de reputación, consecuencias financieras, multas elevadas o incluso demandas judiciales.

Cómo detener ataques de inyección XML

Las inyecciones XML son bastante comunes debido a su facilidad de ejecución y a la prevalencia de las bases de datos XML. Sin embargo, estos ataques existen desde hace mucho tiempo. Por ello, existen varias soluciones definitivas que impedirán que se ejecuten.

Uno de los mejores métodos para detener estos ataques es diseñar la aplicación para que solo utilice consultas XML precompiladas. Esto limita la funcionalidad de las consultas a un subconjunto autorizado de actividades. Cualquier entrada con argumentos o comandos adicionales que no coincidan con las funciones de la consulta precompilada simplemente no se ejecutará. Si no desea ser tan restrictivo, también puede utilizar la parametrización. Esto limita la entrada del usuario a tipos específicos de consultas y datos, por ejemplo, utilizando solo números enteros. Todo lo que quede fuera de esos parámetros se considera inválido y provoca el fallo de la consulta.

También es recomendable combinar las consultas precompiladas o parametrizadas con mensajes de error personalizados. En lugar de devolver los mensajes de error descriptivos predeterminados de una consulta fallida, las aplicaciones deben interceptar esas respuestas y sustituirlas por un mensaje más genérico. Lo ideal es informar al usuario de por qué falló la consulta, pero sin revelar información sobre la base de datos. Si limita esos mensajes personalizados a unas pocas opciones, los atacantes no podrán obtener información útil de las consultas fallidas.

Las inyecciones XML tuvieron mucho éxito cuando aparecieron. Pero dado el tiempo transcurrido, hoy podemos construir fácilmente defensas que ya no pueden ser vulneradas.

Más información sobre las inyecciones XML

Para seguir leyendo, puede consultar el artículo de OWASP sobre inyecciones XML. También puede poner a prueba sus nuevos conocimientos defensivos con la demo gratuita de la plataforma Secure Code Warrior, que entrena a equipos de ciberseguridad para convertirse en expertos. Para saber más sobre cómo derrotar esta vulnerabilidad y otras amenazas, visite el blog de Secure Code Warrior.