Técnica de codificación segura: Procesamiento de datos XML, parte 1
El Lenguaje de Marcas Extensible (XML) es un lenguaje de marcas utilizado para codificar documentos en un formato fácil de manejar para las máquinas y legible para el ser humano. Sin embargo, este formato tan utilizado incluye múltiples fallos de seguridad. En esta primera entrada del blog relacionada con XML, explicaré los fundamentos del manejo de documentos XML de forma segura mediante el uso de un esquema.
OWASP divide las diferentes vulnerabilidades relacionadas con XML y los esquemas XML en dos categorías.
Documentos XML mal formados
Los documentos XML malformados son documentos que no siguen las especificaciones XML del W3C. Algunos ejemplos que dan lugar a un documento malformado son la eliminación de una etiqueta de finalización, el cambio de orden de diferentes elementos o el uso de caracteres prohibidos. Todos estos errores deberían dar lugar a un error fatal y el documento no debería sufrir ningún tratamiento adicional.
Para evitar las vulnerabilidades causadas por los documentos malformados, debe utilizar un analizador XML bien probado que siga las especificaciones del W3C y que no tarde mucho en procesar los documentos malformados.
Documentos XML no válidos
Los documentos XML inválidos están bien formados pero contienen valores inesperados. En este caso, un atacante puede aprovecharse de las aplicaciones que no definen correctamente un esquema XML para identificar si los documentos son válidos. A continuación puede encontrar un ejemplo sencillo de un documento que, si no se valida correctamente, podría tener consecuencias no deseadas.
Una tienda web que almacena sus transacciones en datos XML:
<purchase></purchase>
<id>123</id>
<price>200</price>
And the user only has control over the <id> value. It is then possible, without the right counter measures, for an attacker to input something like this:</id>
<purchase></purchase>
<id>123</id>
<price>0</price>
<id></id>
<price>200</price>
If the parser that processes this document only reads the first instance of the <id> and <price> tags this will lead to unwanted results. </price></id>
También es posible que el esquema no sea lo suficientemente restrictivo o que otras validaciones de entrada sean insuficientes, de modo que se puedan introducir números negativos, decimales especiales (como NaN o Infinito) o valores excesivamente grandes donde no se esperan, lo que lleva a un comportamiento similar no deseado.
Para evitar las vulnerabilidades relacionadas con los documentos XML no válidos se debe definir un esquema XML preciso y restrictivo para evitar problemas de validación de datos inadecuados.
En la próxima entrada del blog nos adentraremos en algunos ataques más avanzados a documentos XML como los Jumbo Payloads y el temido Top Ten de OWASP número cuatro, XXE.
Mientras tanto, puede perfeccionar o desafiar sus habilidades en la validación de entradas XML en nuestro portal.
Las especificaciones para XML y los esquemas XML incluyen múltiples fallos de seguridad. Al mismo tiempo, estas especificaciones proporcionan las herramientas necesarias para proteger las aplicaciones XML. Aunque utilicemos los esquemas XML para definir la seguridad de los documentos XML, pueden utilizarse para realizar diversos ataques: recuperación de archivos, falsificación de peticiones del lado del servidor, escaneo de puertos o fuerza bruta.
Las especificaciones para XML y los esquemas XML incluyen múltiples fallos de seguridad. Al mismo tiempo, estas especificaciones proporcionan las herramientas necesarias para proteger las aplicaciones XML. Aunque utilicemos los esquemas XML para definir la seguridad de los documentos XML, pueden utilizarse para realizar diversos ataques.
Investigador de seguridad de aplicaciones - Ingeniero de I+D - Candidato a doctor
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
Investigador de seguridad de aplicaciones - Ingeniero de I+D - Candidato a doctor
El Lenguaje de Marcas Extensible (XML) es un lenguaje de marcas utilizado para codificar documentos en un formato fácil de manejar para las máquinas y legible para el ser humano. Sin embargo, este formato tan utilizado incluye múltiples fallos de seguridad. En esta primera entrada del blog relacionada con XML, explicaré los fundamentos del manejo de documentos XML de forma segura mediante el uso de un esquema.
OWASP divide las diferentes vulnerabilidades relacionadas con XML y los esquemas XML en dos categorías.
Documentos XML mal formados
Los documentos XML malformados son documentos que no siguen las especificaciones XML del W3C. Algunos ejemplos que dan lugar a un documento malformado son la eliminación de una etiqueta de finalización, el cambio de orden de diferentes elementos o el uso de caracteres prohibidos. Todos estos errores deberían dar lugar a un error fatal y el documento no debería sufrir ningún tratamiento adicional.
Para evitar las vulnerabilidades causadas por los documentos malformados, debe utilizar un analizador XML bien probado que siga las especificaciones del W3C y que no tarde mucho en procesar los documentos malformados.
Documentos XML no válidos
Los documentos XML inválidos están bien formados pero contienen valores inesperados. En este caso, un atacante puede aprovecharse de las aplicaciones que no definen correctamente un esquema XML para identificar si los documentos son válidos. A continuación puede encontrar un ejemplo sencillo de un documento que, si no se valida correctamente, podría tener consecuencias no deseadas.
Una tienda web que almacena sus transacciones en datos XML:
<purchase></purchase>
<id>123</id>
<price>200</price>
And the user only has control over the <id> value. It is then possible, without the right counter measures, for an attacker to input something like this:</id>
<purchase></purchase>
<id>123</id>
<price>0</price>
<id></id>
<price>200</price>
If the parser that processes this document only reads the first instance of the <id> and <price> tags this will lead to unwanted results. </price></id>
También es posible que el esquema no sea lo suficientemente restrictivo o que otras validaciones de entrada sean insuficientes, de modo que se puedan introducir números negativos, decimales especiales (como NaN o Infinito) o valores excesivamente grandes donde no se esperan, lo que lleva a un comportamiento similar no deseado.
Para evitar las vulnerabilidades relacionadas con los documentos XML no válidos se debe definir un esquema XML preciso y restrictivo para evitar problemas de validación de datos inadecuados.
En la próxima entrada del blog nos adentraremos en algunos ataques más avanzados a documentos XML como los Jumbo Payloads y el temido Top Ten de OWASP número cuatro, XXE.
Mientras tanto, puede perfeccionar o desafiar sus habilidades en la validación de entradas XML en nuestro portal.
Las especificaciones para XML y los esquemas XML incluyen múltiples fallos de seguridad. Al mismo tiempo, estas especificaciones proporcionan las herramientas necesarias para proteger las aplicaciones XML. Aunque utilicemos los esquemas XML para definir la seguridad de los documentos XML, pueden utilizarse para realizar diversos ataques: recuperación de archivos, falsificación de peticiones del lado del servidor, escaneo de puertos o fuerza bruta.
El Lenguaje de Marcas Extensible (XML) es un lenguaje de marcas utilizado para codificar documentos en un formato fácil de manejar para las máquinas y legible para el ser humano. Sin embargo, este formato tan utilizado incluye múltiples fallos de seguridad. En esta primera entrada del blog relacionada con XML, explicaré los fundamentos del manejo de documentos XML de forma segura mediante el uso de un esquema.
OWASP divide las diferentes vulnerabilidades relacionadas con XML y los esquemas XML en dos categorías.
Documentos XML mal formados
Los documentos XML malformados son documentos que no siguen las especificaciones XML del W3C. Algunos ejemplos que dan lugar a un documento malformado son la eliminación de una etiqueta de finalización, el cambio de orden de diferentes elementos o el uso de caracteres prohibidos. Todos estos errores deberían dar lugar a un error fatal y el documento no debería sufrir ningún tratamiento adicional.
Para evitar las vulnerabilidades causadas por los documentos malformados, debe utilizar un analizador XML bien probado que siga las especificaciones del W3C y que no tarde mucho en procesar los documentos malformados.
Documentos XML no válidos
Los documentos XML inválidos están bien formados pero contienen valores inesperados. En este caso, un atacante puede aprovecharse de las aplicaciones que no definen correctamente un esquema XML para identificar si los documentos son válidos. A continuación puede encontrar un ejemplo sencillo de un documento que, si no se valida correctamente, podría tener consecuencias no deseadas.
Una tienda web que almacena sus transacciones en datos XML:
<purchase></purchase>
<id>123</id>
<price>200</price>
And the user only has control over the <id> value. It is then possible, without the right counter measures, for an attacker to input something like this:</id>
<purchase></purchase>
<id>123</id>
<price>0</price>
<id></id>
<price>200</price>
If the parser that processes this document only reads the first instance of the <id> and <price> tags this will lead to unwanted results. </price></id>
También es posible que el esquema no sea lo suficientemente restrictivo o que otras validaciones de entrada sean insuficientes, de modo que se puedan introducir números negativos, decimales especiales (como NaN o Infinito) o valores excesivamente grandes donde no se esperan, lo que lleva a un comportamiento similar no deseado.
Para evitar las vulnerabilidades relacionadas con los documentos XML no válidos se debe definir un esquema XML preciso y restrictivo para evitar problemas de validación de datos inadecuados.
En la próxima entrada del blog nos adentraremos en algunos ataques más avanzados a documentos XML como los Jumbo Payloads y el temido Top Ten de OWASP número cuatro, XXE.
Mientras tanto, puede perfeccionar o desafiar sus habilidades en la validación de entradas XML en nuestro portal.
Las especificaciones para XML y los esquemas XML incluyen múltiples fallos de seguridad. Al mismo tiempo, estas especificaciones proporcionan las herramientas necesarias para proteger las aplicaciones XML. Aunque utilicemos los esquemas XML para definir la seguridad de los documentos XML, pueden utilizarse para realizar diversos ataques: recuperación de archivos, falsificación de peticiones del lado del servidor, escaneo de puertos o fuerza bruta.
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ón
Investigador de seguridad de aplicaciones - Ingeniero de I+D - Candidato a doctor
El Lenguaje de Marcas Extensible (XML) es un lenguaje de marcas utilizado para codificar documentos en un formato fácil de manejar para las máquinas y legible para el ser humano. Sin embargo, este formato tan utilizado incluye múltiples fallos de seguridad. En esta primera entrada del blog relacionada con XML, explicaré los fundamentos del manejo de documentos XML de forma segura mediante el uso de un esquema.
OWASP divide las diferentes vulnerabilidades relacionadas con XML y los esquemas XML en dos categorías.
Documentos XML mal formados
Los documentos XML malformados son documentos que no siguen las especificaciones XML del W3C. Algunos ejemplos que dan lugar a un documento malformado son la eliminación de una etiqueta de finalización, el cambio de orden de diferentes elementos o el uso de caracteres prohibidos. Todos estos errores deberían dar lugar a un error fatal y el documento no debería sufrir ningún tratamiento adicional.
Para evitar las vulnerabilidades causadas por los documentos malformados, debe utilizar un analizador XML bien probado que siga las especificaciones del W3C y que no tarde mucho en procesar los documentos malformados.
Documentos XML no válidos
Los documentos XML inválidos están bien formados pero contienen valores inesperados. En este caso, un atacante puede aprovecharse de las aplicaciones que no definen correctamente un esquema XML para identificar si los documentos son válidos. A continuación puede encontrar un ejemplo sencillo de un documento que, si no se valida correctamente, podría tener consecuencias no deseadas.
Una tienda web que almacena sus transacciones en datos XML:
<purchase></purchase>
<id>123</id>
<price>200</price>
And the user only has control over the <id> value. It is then possible, without the right counter measures, for an attacker to input something like this:</id>
<purchase></purchase>
<id>123</id>
<price>0</price>
<id></id>
<price>200</price>
If the parser that processes this document only reads the first instance of the <id> and <price> tags this will lead to unwanted results. </price></id>
También es posible que el esquema no sea lo suficientemente restrictivo o que otras validaciones de entrada sean insuficientes, de modo que se puedan introducir números negativos, decimales especiales (como NaN o Infinito) o valores excesivamente grandes donde no se esperan, lo que lleva a un comportamiento similar no deseado.
Para evitar las vulnerabilidades relacionadas con los documentos XML no válidos se debe definir un esquema XML preciso y restrictivo para evitar problemas de validación de datos inadecuados.
En la próxima entrada del blog nos adentraremos en algunos ataques más avanzados a documentos XML como los Jumbo Payloads y el temido Top Ten de OWASP número cuatro, XXE.
Mientras tanto, puede perfeccionar o desafiar sus habilidades en la validación de entradas XML en nuestro portal.
Las especificaciones para XML y los esquemas XML incluyen múltiples fallos de seguridad. Al mismo tiempo, estas especificaciones proporcionan las herramientas necesarias para proteger las aplicaciones XML. Aunque utilicemos los esquemas XML para definir la seguridad de los documentos XML, pueden utilizarse para realizar diversos ataques: recuperación de archivos, falsificación de peticiones del lado del servidor, escaneo de puertos o fuerza bruta.
Índice
Investigador de seguridad de aplicaciones - Ingeniero de I+D - Candidato a doctor
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
Asistentes de codificación de IA: Guía de navegación segura para la próxima generación de desarrolladores
Los grandes modelos lingüísticos ofrecen ventajas irresistibles en velocidad y productividad, pero también introducen riesgos innegables para la empresa. Las barandillas de seguridad tradicionales no bastan para controlar el diluvio. Los desarrolladores necesitan conocimientos de seguridad precisos y verificados para identificar y prevenir los fallos de seguridad desde el principio del ciclo de vida de desarrollo del software.
Seguridad desde el diseño: Definición de las mejores prácticas, capacitación de los desarrolladores y evaluación comparativa de los resultados de la seguridad preventiva
En este documento de investigación, los cofundadores Secure Code Warrior , Pieter Danhieux y el Dr. Matias Madou, Ph.D., junto con los expertos colaboradores, Chris Inglis, ex Director Nacional Cibernético de EE.UU. (ahora Asesor Estratégico de Paladin Capital Group), y Devin Lynch, Director Senior, Paladin Global Institute, revelarán los hallazgos clave de más de veinte entrevistas en profundidad con líderes de seguridad empresarial, incluyendo CISOs, un VP de Seguridad de Aplicaciones y profesionales de seguridad de software.
Recursos para empezar
Más de 10.000 actividades de aprendizaje sobre código seguro: Una década de gestión de riesgos para desarrolladores
Más de 10 000 actividades de aprendizaje de código seguro y una década ayudando a los desarrolladores a reducir riesgos, mejorar la calidad del código y abordar con confianza el desarrollo asistido por IA.
.jpg)
Estableciendo el estándar: SCW publica reglas de seguridad de codificación de IA gratuitas en GitHub
El desarrollo asistido por IA ya no es una posibilidad: ya está aquí y está transformando rápidamente la forma de escribir software. Herramientas como GitHub Copilot, Cline, Roo, Cursor, Aider y Windsurf están transformando a los desarrolladores en sus propios copilotos, permitiendo iteraciones más rápidas y acelerando todo, desde la creación de prototipos hasta grandes proyectos de refactorización.
Cierre el círculo de las vulnerabilidades con Secure Code Warrior + HackerOne
Secure Code Warrior se complace en anunciar nuestra nueva integración con HackerOne, líder en soluciones de seguridad ofensiva. Juntos, estamos construyendo un ecosistema potente e integrado. HackerOne señala dónde se producen realmente las vulnerabilidades en entornos reales, exponiendo el "qué" y el "dónde" de los problemas de seguridad.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
