Coders Conquer Security: Share & Learn Series - Inyecciones XML

Los ataques de inyección XML son pequeños y desagradables exploits inventados por los hackers para ayudarles a comprometer los sistemas que alojan bases de datos XML. Esto incluye el tipo de cosas que vienen a la mente cuando uno piensa en las bases de datos tradicionales: almacenes detallados de información sobre cualquier cosa, desde medicamentos hasta películas. Algunos almacenes de datos XML también se utilizan para comprobar si hay usuarios autorizados, por lo que inyectar nuevo código XML en ellos puede crear nuevos usuarios que el sistema anfitrión aceptará a partir de ese momento.

Para que un atacante implemente una inyección XML, es necesario que haya una aplicación que dependa de una base de datos XML, o que al menos acceda a ella. Cuando esto ocurre, y la entrada del usuario no es debidamente vetada, 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 hacer bastante daño, o incluso proporcionar acceso a toda la base de datos.

A medida que vayas leyendo, puede que descubras que la inyección XML está estrechamente relacionada con los ataques de inyección SQL que hemos tratado anteriormente. Esto se debe a que, aunque se dirigen a diferentes tipos de bases de datos, son extremadamente similares. Y por suerte, las soluciones también son similares. Si aprende a derrotar un tipo de ataque, llevará la delantera a la hora de prevenir el otro.

En este episodio, aprenderemos:

• Cómo funcionan las inyecciones XML
• Por qué son tan peligrosos
• Cómo puede poner defensas para detenerlos completamente.

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

Las inyecciones XML tienen éxito cuando un usuario no autorizado es capaz de escribir código XML e insertarlo en una base de datos XML existente. Esto sólo requiere dos cosas para funcionar: una aplicación que dependa de una base de datos XML, o que se conecte a ella, y una vía de datos no segura para que el atacante pueda lanzar su ataque.

Las inyecciones XML son casi siempre exitosas si la entrada del usuario no es desinfectada o restringida de alguna manera antes de ser enviada 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, permitiéndole 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 cosas como cookies o cabeceras.

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 está empleando buenas reglas de densidad de contraseñas. Lástima que en realidad sea un atacante.

Los piratas informáticos no tienen por qué dar siempre un golpe como ese para tener éxito con las inyecciones XML. Manipulando sus consultas y registrando los diversos mensajes de error que devuelve el servidor, pueden ser capaces de trazar 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 de un ataque de inyección 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 una base de datos XML que se utiliza para autenticar a los 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 que por supuesto es una situación extremadamente peligrosa.

En el caso de las inyecciones XML contra bases de datos más tradicionales, el peligro está en que se robe esa información, que se añadan datos incorrectos al almacén o que se sobrescriban datos buenos. El código XML no es muy difícil de aprender, y algunos de los comandos pueden ser extremadamente poderosos, sobrescribiendo campos enteros de información 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 piratas informáticos lo saben, y por eso suelen atacarlas. Si esos datos incluyen cosas como información personal de empleados o clientes, tenerlos comprometidos puede llevar a la pérdida de reputación, consecuencias financieras, fuertes multas o incluso demandas.  

Cómo detener los ataques de inyección XML

Las inyecciones XML son bastante comunes debido al bajo grado de dificultad para llevar a cabo una, y la prevalencia de las bases de datos XML. Pero estos ataques existen desde hace mucho tiempo. Por lo tanto, hay varias correcciones de hierro que impedirán que se ejecuten.

Uno de los mejores métodos para detener los ataques es diseñar una aplicación que sólo utilice consultas XML precompiladas. Esto limita la funcionalidad de las consultas a un subconjunto autorizado de actividades. Cualquier cosa que entre con argumentos extra o comandos que no coincidan con las funciones de consulta precompiladas simplemente no se ejecutará. Si no quiere ser tan restrictivo, también puede utilizar la parametrización. Esto restringe la entrada del usuario a tipos específicos de consultas y datos, por ejemplo, sólo usando números enteros. Cualquier cosa que quede fuera de esos parámetros se considera inválida y obliga a que la consulta falle.

También es una buena idea emparejar las consultas precompiladas o parametrizadas con mensajes de error personalizados. En lugar de devolver los mensajes de error descriptivos por defecto de una consulta fallida, las aplicaciones deberían interceptar esas respuestas y sustituirlas por un mensaje más genérico. Lo ideal es decirle al usuario por qué ha fallado la consulta, pero no darle ninguna información sobre la propia base de datos. Si restringes esos mensajes personalizados a unas pocas opciones, los hackers no podrán recopilar ningún reconocimiento útil de las consultas fallidas.

Las inyecciones XML tuvieron mucho éxito cuando se desarrollaron por primera vez. Pero teniendo en cuenta el tiempo que pasó, hoy podemos construir fácilmente defensas que ya no pueden ser vulneradas.

Más información sobre XML Injections

Para más información, puedes consultar el artículo de OWASP sobre inyecciones XML. También puedes poner a prueba tus nuevos conocimientos defensivos con la demostración gratuita de la plataforma Secure Code Warrior , que forma a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para saber más sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .