Los codificadores conquistan la seguridad: serie Share & Learn - Inyecciones de XML

Los ataques de inyección de XML son pequeños exploits desagradables inventados por piratas informáticos para ayudarlos a comprometer los sistemas que alojan bases de datos XML. Esto incluye el tipo de cosas que se nos vienen a la mente cuando pensamos en las bases de datos tradicionales: almacenes detallados de información sobre cualquier tema, desde medicamentos hasta películas. Algunos almacenes de datos XML también se utilizan para comprobar si hay usuarios autorizados, por lo que si se les inyecta código XML nuevo, se pueden crear nuevos usuarios que el sistema anfitrión aceptará a partir de ese momento.

Para que un atacante pueda implementar una inyección de XML, es necesario que haya una aplicación que dependa de una base de datos XML, o al menos acceda a ella. Siempre que esto ocurra y las entradas del usuario no se examinen correctamente, se puede agregar un nuevo código XML al almacén de datos. Dependiendo de la habilidad del atacante, añadir un nuevo código XML puede causar mucho daño o incluso proporcionar acceso a toda la base de datos.

A medida que siga leyendo, es posible que descubra que la inyección de XML está estrechamente relacionada con los ataques de inyección de SQL que hemos cubierto anteriormente. Esto se debe a que, aunque se dirigen a diferentes tipos de bases de datos, son extremadamente similares. Y, afortunadamente, las soluciones también son similares. Aprender a derrotar un tipo de ataque te pondrá muy por delante del juego a la hora de prevenir el otro.

En este episodio, aprenderemos:

• Cómo funcionan las inyecciones de XML
• Por qué son tan peligrosos
• Cómo puedes establecer defensas para detenerlos por completo.

¿Cómo activan los atacantes las inyecciones de XML?

Las inyecciones de XML se realizan correctamente siempre que un usuario no autorizado puede escribir código XML e insertarlo en una base de datos XML existente. Esto solo requiere dos cosas para funcionar: una aplicación que dependa de una base de datos XML o se conecte a ella y una ruta de datos no segura para que el atacante lance su ataque.

Las inyecciones de XML casi siempre tienen éxito si la entrada del usuario no se sanea o restringe de otro modo antes de enviarla a un servidor para su procesamiento. Esto puede permitir a los atacantes escribir su propio código, o inyectarlo, al final de su cadena de consulta normal. Si tiene éxito, esto engaña 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 piratas informáticos implementan un ataque de inyección de XML añadiendo código XML a una consulta normal. 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 puede agregar el siguiente código después del campo de nombre de usuario o contraseña:

<user></user>
<role>administrador</role>
<username>John_Smith Jump 783!</username> <password> Tango @12</password>

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

Los hackers no tienen por qué hacer siempre un jonrón como ese para tener éxito con las inyecciones de XML. Al manipular sus consultas y registrar los distintos mensajes de error que devuelve el servidor, es posible que puedan trazar la estructura de la base de datos XML. Y esa información se puede utilizar para mejorar otros tipos de ataques.

¿Por qué son tan peligrosas las inyecciones de XML?

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

En el caso de las inyecciones de XML aplicadas a bases de datos más tradicionales, existe el peligro de que roben esa información, de que se añadan datos incorrectos al almacén o de que se sobrescriban datos en buen estado. El código XML no es muy difícil de aprender y algunos de los comandos pueden ser extremadamente eficaces, ya que sobrescriben campos de información completos o incluso muestran el contenido de un almacén de datos.

Por lo general, nadie crea una base de datos a menos que la información almacenada en ella tenga valor. Los piratas informáticos lo saben y por eso suelen atacarlos. Si esos datos incluyen datos como información personal de empleados o clientes, ponerlos en peligro puede provocar la pérdida de reputación, consecuencias financieras, fuertes multas o incluso demandas.

Detener los ataques de inyección de XML

Las inyecciones de XML son bastante comunes debido al bajo grado de dificultad para llevarlas a cabo y a la prevalencia de las bases de datos XML. Sin embargo, estos ataques existen desde hace mucho tiempo. Como tal, hay varias soluciones irrefutables que evitarán que se ejecuten alguna vez.

Uno de los mejores métodos para detener los ataques es diseñar una aplicación que solo utilice consultas XML precompiladas. Esto limita la funcionalidad de las consultas a un subconjunto autorizado de actividades. Todo lo que venga con argumentos o comandos adicionales que no coincidan con las funciones de consulta precompiladas simplemente no se ejecutará. Si no quieres ser tan restrictivo, también puedes usar la parametrización. Esto restringe la entrada del usuario a tipos específicos de consultas y datos; por ejemplo, solo usa números enteros. Todo lo que quede fuera de esos parámetros se considera inválido y hace que la consulta falle.

También es una buena idea combinar 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 deberían interceptar esas respuestas y sustituirlas por un mensaje más genérico. Lo ideal sería decirle al usuario por qué falló la consulta, pero no darle ninguna información sobre la base de datos en sí. Si restringe esos mensajes personalizados a unas pocas opciones, los piratas informáticos no podrán recopilar ningún reconocimiento útil de las consultas fallidas.

Las inyecciones de XML tuvieron un gran éxito cuando se desarrollaron por primera vez. Pero teniendo en cuenta cuánto tiempo pasó, hoy podemos construir fácilmente defensas que ya no se pueden romper.

Más información sobre las inyecciones de XML

Para leer más, puede echar un vistazo al OWASP artículo sobre Inyecciones de XML. También puede poner a prueba sus nuevos conocimientos defensivos con el demo gratuita de la plataforma Secure Code Warrior, que forma a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para obtener más información sobre cómo derrotar esta vulnerabilidad y la galería de otras amenazas de los delincuentes, visita la Blog de Secure Code Warrior.