it-swarm-es.com

Si un documento XML no se valida como "Bien formado" o no se compara con un esquema, ¿cuáles son los riesgos?

Al procesar un documento XML en mi aplicación, ¿cuáles son los riesgos? P.ej. si no está "Bien formado" o no se compara con un esquema.

11
Phoenician-Eagle

Incluso si tiene un documento XML "bien formado", eso no evita el ataque; la inyección no siempre rompe el documento XML. Para evitar ataques de inyección de XML, las siguientes medidas deberían ayudar:

  • compruebe la definición de esquema XML válida;
  • validar/desinfectar la entrada;
  • verificar y hacer cumplir la codificación;

Para completar mi respuesta, quiero agregar varios enlaces útiles:

8
anonymous

El procesamiento seguro de XML usando DTD y XSD es complicado.

Debe asegurarse de que se haga referencia a los dtd y xsd correctos para su caso de uso antes de procesar el archivo xml con un analizador (y que no se agregue contenido xml mixto, como xmlns alternativos, definiciones de dtd locales en xml, expansiones de entidades, etc.).

Como escuché en un podcast de OWASP descargas de podcasts de OWASP aquí , y es particularmente relevante en este contexto, haga una lista blanca de sus datos aceptados (contenido xml), nunca ponga en una lista negra sus problemas conocidos con ese contenido.

Desactivar las referencias externas es genial (piense en alguien que lea su archivo/etc/passwd o/etc/shadow haciendo referencia a él usando el protocolo file: // en lugar del dtd).

Puede usar un solucionador y un archivo de catálogo para controlar/reemplazar referencias externas con copias locales buenas conocidas que no se pueden subvertir http://xml.Apache.org/commons/components/resolver/resolver-article.html

Puede utilizar un programa/biblioteca de validación extrínseca, como el validador de múltiples esquemas de Sun/Oracle. http://msv.Java.net/ esto puede proporcionar validación incluso cuando no hay nada que validar internamente, y puede usar una tecnología diferente/complementaria como RELAX NG = para validar su xml.

Tenga cuidado con todo tipo de inyecciones (SQL, Javascript, xmlns, image, svg, url, xslt, xpath, etc.) porque todas pueden potencialmente inyectarse y transmitirse a un contexto dentro del cual se activan y se convierten en un peligro para su servidor de base de datos. servidor de aplicaciones o sus entornos de cliente. Considere una imagen codificada en base64 con un compromiso IE) que se transmite a una página web dentro de su infraestructura (juego terminado).

La denegación de servicio en su infraestructura de procesamiento xml también puede ser una preocupación, pero puede no ser relevante para su sistema.

Nota: @anonymous ha proporcionado algunas URL excelentes para recursos relevantes.

6
Andrew Russell

El riesgo principal de no verificar la sintaxis de su XML es el análisis no válido.

Si el software que lee el XML no puede manejar entradas no válidas, podría fallar, hacer algo inesperado, explotar espontáneamente (probablemente no), etc. Esas situaciones pueden conducir a fallas de seguridad, pero si el software es lo suficientemente frágil como para no poder hacerlo. manejar XML no válido, es muy probable que tenga otras fallas de seguridad, potencialmente incluso en los datos "válidos".

Como analogía, la mayoría de los agujeros de seguridad de las aplicaciones web (por ejemplo, la inyección de SQL) no se atacan utilizando HTML no válido, sino una entrada sintácticamente válida que causa problemas cuando se analiza. En su caso, el XML es la entrada. La verificación del esquema rara vez es suficiente para validar la entrada, especialmente si el XSD/DTD/lo que sea se generó automáticamente. Cualquiera que sea el proceso, la entrada en la propia aplicación también debe verificarla.

5
Shewfig