Coders Conquer Security: Share & Learn Series - Inyección XXE
El ataque XML External Entity Injection, a veces simplemente abreviado como inyección XXE, es relativamente nuevo en comparación con algunas de las vulnerabilidades clásicas que siguen dando vueltas años después de su creación. Pero es extremadamente popular entre las comunidades de hackers en este momento, y crece aún más a medida que acumula éxitos.
De hecho, OWASP incluye ahora la inyección XXE como una de las diez principales vulnerabilidades que los sitios deben vigilar y contra las que deben defenderse activamente. Pero no te preocupes, la inyección XXE no es más poderosa que otros exploits que se despliegan en los ciberataques. Simplemente es un poco más nuevo y un poco menos conocido. Se puede prevenir y, de hecho, detener por completo.
En este episodio aprenderemos:
- Cómo utilizan los atacantes las inyecciones XXE
- Por qué es peligrosa la inyección de XXE
- Técnicas que pueden evitar esta vulnerabilidad.
¿Cómo se desencadena una inyección de XXE por parte de los atacantes?
La vulnerabilidad de inyección XXE puede ocurrir cuando un usuario malicioso tiene la capacidad de enviar código XML. Utilizan esta capacidad para crear una referencia a una entidad externa. La referencia externa y el código están diseñados para pasar por un analizador XML con la configuración por defecto, o uno con una configuración débil.
El atacante explota el hecho de que el estándar XML define el concepto de entidad como una unidad de almacenamiento de algún tipo, pero ese almacenamiento puede ser externo o interno. Utilizado correctamente, puede permitir a los procesadores XML acceder a recursos remotos. La mayoría de las veces, los atacantes utilizan esta capacidad para hacer cosas como sondear la estructura interna de un sitio web, lanzar un ataque de denegación de servicio activando grandes procesos del sistema que intentan acceder a recursos remotos, o incluso volcar datos de un host local a uno remoto que controlan " por lo que es una buena técnica para exfiltrar datos importantes como contraseñas o información personal contenida en la base de datos XML.
El código real involucrado en el ataque es a menudo bastante simplista, simplemente explotando la funcionalidad de la entidad. Por ejemplo, esto podría permitir a un hacker acceder al archivo de la contraseña maestra:
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
¿Por qué es peligrosa la inyección de XXE?
Hay algunas razones por las que los ataques de inyección XXE son tan peligrosos, y también frecuentes. Por un lado, es una vulnerabilidad menos conocida en este momento. Y las ganancias que puede obtener un atacante al explotarla son considerables. Por un lado, puede permitir a los atacantes persistentes mapear lentamente todas las rutas en una red interna o incluso escanear puertos. Aunque esto puede llevar bastante tiempo, no hay casi ninguna posibilidad de que la actividad de un hacker sea descubierta por las defensas activas de la red objetivo porque simplemente están enviando código XML a un servidor que está siendo limpiado por el parser XML de confianza.
Una vez mapeado, los atacantes pueden utilizar las mismas técnicas de inyección de XXE para capturar los archivos que necesiten, ya sea robando directamente la información o comprometiendo las credenciales de usuario válidas y utilizándolas para ataques secundarios. Por último, los atacantes que sólo quieren hacer ruido y ser maliciosos pueden hacer cosas como desencadenar ataques de denegación de servicio, ordenando a la aplicación que intente acceder a recursos distantes diseñados para empantanar el sistema.
Eliminación de la vulnerabilidad de inyección XXE
Debido al rápido aumento de los ataques de inyección XXE, muchos analizadores XML están empezando a deshabilitar las entidades externas, a veces llamadas DTD, completamente por defecto. Para ellos, la clave es simplemente no habilitar esa funcionalidad.
Pero incluso los parsers que permiten DTDs pueden tener esa funcionalidad desactivada. En general, una declaración como la siguiente va a ser necesaria para bloquearla completamente, pero compruebe la documentación de su framework local para obtener el código exacto necesario.
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
Siguiendo los principios de seguridad, toda la entrada del usuario debe ser saneada y validada utilizando filtros a nivel de aplicación. No olvides incluir los parámetros GET y POST, las cabeceras HTTP y las cookies. También puedes crear una lista blanca de DTDs y comandos específicos que quieres que el analizador procese, y no permitir todo lo demás.
Aunque las listas blancas y el filtrado funcionan, debido al creciente número de ataques de inyección de XXE, se sigue recomendando desactivar completamente el soporte de DTD si la funcionalidad no es necesaria.
Más información sobre XXE Injections
Para más información, puede consultar lo que dice la OWASP sobre los ataques de inyección XXE. 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 .


El ataque XML External Entity Injection, a veces simplemente abreviado como inyección XXE, es relativamente nuevo, pero es extremadamente popular entre las comunidades de hackers en este momento, y crece aún más a medida que acumula éxitos.

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostración

El ataque XML External Entity Injection, a veces simplemente abreviado como inyección XXE, es relativamente nuevo en comparación con algunas de las vulnerabilidades clásicas que siguen dando vueltas años después de su creación. Pero es extremadamente popular entre las comunidades de hackers en este momento, y crece aún más a medida que acumula éxitos.
De hecho, OWASP incluye ahora la inyección XXE como una de las diez principales vulnerabilidades que los sitios deben vigilar y contra las que deben defenderse activamente. Pero no te preocupes, la inyección XXE no es más poderosa que otros exploits que se despliegan en los ciberataques. Simplemente es un poco más nuevo y un poco menos conocido. Se puede prevenir y, de hecho, detener por completo.
En este episodio aprenderemos:
- Cómo utilizan los atacantes las inyecciones XXE
- Por qué es peligrosa la inyección de XXE
- Técnicas que pueden evitar esta vulnerabilidad.
¿Cómo se desencadena una inyección de XXE por parte de los atacantes?
La vulnerabilidad de inyección XXE puede ocurrir cuando un usuario malicioso tiene la capacidad de enviar código XML. Utilizan esta capacidad para crear una referencia a una entidad externa. La referencia externa y el código están diseñados para pasar por un analizador XML con la configuración por defecto, o uno con una configuración débil.
El atacante explota el hecho de que el estándar XML define el concepto de entidad como una unidad de almacenamiento de algún tipo, pero ese almacenamiento puede ser externo o interno. Utilizado correctamente, puede permitir a los procesadores XML acceder a recursos remotos. La mayoría de las veces, los atacantes utilizan esta capacidad para hacer cosas como sondear la estructura interna de un sitio web, lanzar un ataque de denegación de servicio activando grandes procesos del sistema que intentan acceder a recursos remotos, o incluso volcar datos de un host local a uno remoto que controlan " por lo que es una buena técnica para exfiltrar datos importantes como contraseñas o información personal contenida en la base de datos XML.
El código real involucrado en el ataque es a menudo bastante simplista, simplemente explotando la funcionalidad de la entidad. Por ejemplo, esto podría permitir a un hacker acceder al archivo de la contraseña maestra:
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
¿Por qué es peligrosa la inyección de XXE?
Hay algunas razones por las que los ataques de inyección XXE son tan peligrosos, y también frecuentes. Por un lado, es una vulnerabilidad menos conocida en este momento. Y las ganancias que puede obtener un atacante al explotarla son considerables. Por un lado, puede permitir a los atacantes persistentes mapear lentamente todas las rutas en una red interna o incluso escanear puertos. Aunque esto puede llevar bastante tiempo, no hay casi ninguna posibilidad de que la actividad de un hacker sea descubierta por las defensas activas de la red objetivo porque simplemente están enviando código XML a un servidor que está siendo limpiado por el parser XML de confianza.
Una vez mapeado, los atacantes pueden utilizar las mismas técnicas de inyección de XXE para capturar los archivos que necesiten, ya sea robando directamente la información o comprometiendo las credenciales de usuario válidas y utilizándolas para ataques secundarios. Por último, los atacantes que sólo quieren hacer ruido y ser maliciosos pueden hacer cosas como desencadenar ataques de denegación de servicio, ordenando a la aplicación que intente acceder a recursos distantes diseñados para empantanar el sistema.
Eliminación de la vulnerabilidad de inyección XXE
Debido al rápido aumento de los ataques de inyección XXE, muchos analizadores XML están empezando a deshabilitar las entidades externas, a veces llamadas DTD, completamente por defecto. Para ellos, la clave es simplemente no habilitar esa funcionalidad.
Pero incluso los parsers que permiten DTDs pueden tener esa funcionalidad desactivada. En general, una declaración como la siguiente va a ser necesaria para bloquearla completamente, pero compruebe la documentación de su framework local para obtener el código exacto necesario.
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
Siguiendo los principios de seguridad, toda la entrada del usuario debe ser saneada y validada utilizando filtros a nivel de aplicación. No olvides incluir los parámetros GET y POST, las cabeceras HTTP y las cookies. También puedes crear una lista blanca de DTDs y comandos específicos que quieres que el analizador procese, y no permitir todo lo demás.
Aunque las listas blancas y el filtrado funcionan, debido al creciente número de ataques de inyección de XXE, se sigue recomendando desactivar completamente el soporte de DTD si la funcionalidad no es necesaria.
Más información sobre XXE Injections
Para más información, puede consultar lo que dice la OWASP sobre los ataques de inyección XXE. 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 .

El ataque XML External Entity Injection, a veces simplemente abreviado como inyección XXE, es relativamente nuevo en comparación con algunas de las vulnerabilidades clásicas que siguen dando vueltas años después de su creación. Pero es extremadamente popular entre las comunidades de hackers en este momento, y crece aún más a medida que acumula éxitos.
De hecho, OWASP incluye ahora la inyección XXE como una de las diez principales vulnerabilidades que los sitios deben vigilar y contra las que deben defenderse activamente. Pero no te preocupes, la inyección XXE no es más poderosa que otros exploits que se despliegan en los ciberataques. Simplemente es un poco más nuevo y un poco menos conocido. Se puede prevenir y, de hecho, detener por completo.
En este episodio aprenderemos:
- Cómo utilizan los atacantes las inyecciones XXE
- Por qué es peligrosa la inyección de XXE
- Técnicas que pueden evitar esta vulnerabilidad.
¿Cómo se desencadena una inyección de XXE por parte de los atacantes?
La vulnerabilidad de inyección XXE puede ocurrir cuando un usuario malicioso tiene la capacidad de enviar código XML. Utilizan esta capacidad para crear una referencia a una entidad externa. La referencia externa y el código están diseñados para pasar por un analizador XML con la configuración por defecto, o uno con una configuración débil.
El atacante explota el hecho de que el estándar XML define el concepto de entidad como una unidad de almacenamiento de algún tipo, pero ese almacenamiento puede ser externo o interno. Utilizado correctamente, puede permitir a los procesadores XML acceder a recursos remotos. La mayoría de las veces, los atacantes utilizan esta capacidad para hacer cosas como sondear la estructura interna de un sitio web, lanzar un ataque de denegación de servicio activando grandes procesos del sistema que intentan acceder a recursos remotos, o incluso volcar datos de un host local a uno remoto que controlan " por lo que es una buena técnica para exfiltrar datos importantes como contraseñas o información personal contenida en la base de datos XML.
El código real involucrado en el ataque es a menudo bastante simplista, simplemente explotando la funcionalidad de la entidad. Por ejemplo, esto podría permitir a un hacker acceder al archivo de la contraseña maestra:
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
¿Por qué es peligrosa la inyección de XXE?
Hay algunas razones por las que los ataques de inyección XXE son tan peligrosos, y también frecuentes. Por un lado, es una vulnerabilidad menos conocida en este momento. Y las ganancias que puede obtener un atacante al explotarla son considerables. Por un lado, puede permitir a los atacantes persistentes mapear lentamente todas las rutas en una red interna o incluso escanear puertos. Aunque esto puede llevar bastante tiempo, no hay casi ninguna posibilidad de que la actividad de un hacker sea descubierta por las defensas activas de la red objetivo porque simplemente están enviando código XML a un servidor que está siendo limpiado por el parser XML de confianza.
Una vez mapeado, los atacantes pueden utilizar las mismas técnicas de inyección de XXE para capturar los archivos que necesiten, ya sea robando directamente la información o comprometiendo las credenciales de usuario válidas y utilizándolas para ataques secundarios. Por último, los atacantes que sólo quieren hacer ruido y ser maliciosos pueden hacer cosas como desencadenar ataques de denegación de servicio, ordenando a la aplicación que intente acceder a recursos distantes diseñados para empantanar el sistema.
Eliminación de la vulnerabilidad de inyección XXE
Debido al rápido aumento de los ataques de inyección XXE, muchos analizadores XML están empezando a deshabilitar las entidades externas, a veces llamadas DTD, completamente por defecto. Para ellos, la clave es simplemente no habilitar esa funcionalidad.
Pero incluso los parsers que permiten DTDs pueden tener esa funcionalidad desactivada. En general, una declaración como la siguiente va a ser necesaria para bloquearla completamente, pero compruebe la documentación de su framework local para obtener el código exacto necesario.
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
Siguiendo los principios de seguridad, toda la entrada del usuario debe ser saneada y validada utilizando filtros a nivel de aplicación. No olvides incluir los parámetros GET y POST, las cabeceras HTTP y las cookies. También puedes crear una lista blanca de DTDs y comandos específicos que quieres que el analizador procese, y no permitir todo lo demás.
Aunque las listas blancas y el filtrado funcionan, debido al creciente número de ataques de inyección de XXE, se sigue recomendando desactivar completamente el soporte de DTD si la funcionalidad no es necesaria.
Más información sobre XXE Injections
Para más información, puede consultar lo que dice la OWASP sobre los ataques de inyección XXE. 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 .

Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostraciónEl ataque XML External Entity Injection, a veces simplemente abreviado como inyección XXE, es relativamente nuevo en comparación con algunas de las vulnerabilidades clásicas que siguen dando vueltas años después de su creación. Pero es extremadamente popular entre las comunidades de hackers en este momento, y crece aún más a medida que acumula éxitos.
De hecho, OWASP incluye ahora la inyección XXE como una de las diez principales vulnerabilidades que los sitios deben vigilar y contra las que deben defenderse activamente. Pero no te preocupes, la inyección XXE no es más poderosa que otros exploits que se despliegan en los ciberataques. Simplemente es un poco más nuevo y un poco menos conocido. Se puede prevenir y, de hecho, detener por completo.
En este episodio aprenderemos:
- Cómo utilizan los atacantes las inyecciones XXE
- Por qué es peligrosa la inyección de XXE
- Técnicas que pueden evitar esta vulnerabilidad.
¿Cómo se desencadena una inyección de XXE por parte de los atacantes?
La vulnerabilidad de inyección XXE puede ocurrir cuando un usuario malicioso tiene la capacidad de enviar código XML. Utilizan esta capacidad para crear una referencia a una entidad externa. La referencia externa y el código están diseñados para pasar por un analizador XML con la configuración por defecto, o uno con una configuración débil.
El atacante explota el hecho de que el estándar XML define el concepto de entidad como una unidad de almacenamiento de algún tipo, pero ese almacenamiento puede ser externo o interno. Utilizado correctamente, puede permitir a los procesadores XML acceder a recursos remotos. La mayoría de las veces, los atacantes utilizan esta capacidad para hacer cosas como sondear la estructura interna de un sitio web, lanzar un ataque de denegación de servicio activando grandes procesos del sistema que intentan acceder a recursos remotos, o incluso volcar datos de un host local a uno remoto que controlan " por lo que es una buena técnica para exfiltrar datos importantes como contraseñas o información personal contenida en la base de datos XML.
El código real involucrado en el ataque es a menudo bastante simplista, simplemente explotando la funcionalidad de la entidad. Por ejemplo, esto podría permitir a un hacker acceder al archivo de la contraseña maestra:
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
¿Por qué es peligrosa la inyección de XXE?
Hay algunas razones por las que los ataques de inyección XXE son tan peligrosos, y también frecuentes. Por un lado, es una vulnerabilidad menos conocida en este momento. Y las ganancias que puede obtener un atacante al explotarla son considerables. Por un lado, puede permitir a los atacantes persistentes mapear lentamente todas las rutas en una red interna o incluso escanear puertos. Aunque esto puede llevar bastante tiempo, no hay casi ninguna posibilidad de que la actividad de un hacker sea descubierta por las defensas activas de la red objetivo porque simplemente están enviando código XML a un servidor que está siendo limpiado por el parser XML de confianza.
Una vez mapeado, los atacantes pueden utilizar las mismas técnicas de inyección de XXE para capturar los archivos que necesiten, ya sea robando directamente la información o comprometiendo las credenciales de usuario válidas y utilizándolas para ataques secundarios. Por último, los atacantes que sólo quieren hacer ruido y ser maliciosos pueden hacer cosas como desencadenar ataques de denegación de servicio, ordenando a la aplicación que intente acceder a recursos distantes diseñados para empantanar el sistema.
Eliminación de la vulnerabilidad de inyección XXE
Debido al rápido aumento de los ataques de inyección XXE, muchos analizadores XML están empezando a deshabilitar las entidades externas, a veces llamadas DTD, completamente por defecto. Para ellos, la clave es simplemente no habilitar esa funcionalidad.
Pero incluso los parsers que permiten DTDs pueden tener esa funcionalidad desactivada. En general, una declaración como la siguiente va a ser necesaria para bloquearla completamente, pero compruebe la documentación de su framework local para obtener el código exacto necesario.
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
Siguiendo los principios de seguridad, toda la entrada del usuario debe ser saneada y validada utilizando filtros a nivel de aplicación. No olvides incluir los parámetros GET y POST, las cabeceras HTTP y las cookies. También puedes crear una lista blanca de DTDs y comandos específicos que quieres que el analizador procese, y no permitir todo lo demás.
Aunque las listas blancas y el filtrado funcionan, debido al creciente número de ataques de inyección de XXE, se sigue recomendando desactivar completamente el soporte de DTD si la funcionalidad no es necesaria.
Más información sobre XXE Injections
Para más información, puede consultar lo que dice la OWASP sobre los ataques de inyección XXE. 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 .
Índice

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
Servicios profesionales - Acelerar con experiencia
El equipo de servicios de estrategia de programas (PSS) de Secure Code Warriorle ayuda a crear, mejorar y optimizar su programa de codificación segura. Tanto si empieza de cero como si está perfeccionando su enfoque, nuestros expertos le proporcionarán orientación personalizada.
Temas y contenidos de la formación sobre código seguro
Nuestro contenido, líder en el sector, evoluciona constantemente para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Temas que cubren todo, desde IA a XQuery Injection, ofrecidos para una variedad de roles desde Arquitectos e Ingenieros a Product Managers y QA. Eche un vistazo a lo que ofrece nuestro catálogo de contenidos por tema y función.
Búsqueda: Aprendizaje líder en la industria para mantener a los desarrolladores por delante mitigando el riesgo.
Quests es una learning platform que ayuda a los desarrolladores a mitigar los riesgos de seguridad del software mediante la mejora de sus habilidades de codificación segura. Con rutas de aprendizaje curadas, desafíos prácticos y actividades interactivas, capacita a los desarrolladores para identificar y prevenir vulnerabilidades.
Recursos para empezar
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.
La Década de los Defensores: Secure Code Warrior Cumple Diez Años
Secure Code Warriorha permanecido unido, dirigiendo el barco a través de cada lección, triunfo y contratiempo durante toda una década. Estamos creciendo y listos para afrontar nuestro próximo capítulo, SCW 2.0, como líderes en gestión de riesgos para desarrolladores.