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
Panorama de la gestión de riesgos de los promotores
La gestión de riesgos del desarrollador es un enfoque holístico y proactivo de la seguridad de las aplicaciones, centrado en quienes contribuyen al código y no en los bits y bytes de la propia capa de la aplicación.
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.
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.
Recursos para empezar
Revelado: Cómo define el sector cibernético la seguridad por diseño
En nuestro último libro blanco, nuestros cofundadores, Pieter Danhieux y el doctor Matias Madou, se sentaron con más de veinte líderes de seguridad empresarial, incluidos CISO, líderes de AppSec y profesionales de la seguridad, para averiguar las piezas clave de este rompecabezas y descubrir la realidad detrás del movimiento Secure by Design. Se trata de una ambición compartida por todos los equipos de seguridad, pero no de un libro de jugadas compartido.
¿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.
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.
