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.
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.
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:
Para completar mi respuesta, quiero agregar varios enlaces útiles:
El procesamiento seguro de XML con 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 mixto de xml, como xmlns alternativos, definiciones locales de dtd en el xml, expansiones de entidades, etc. ).
Como escuché en un podcast de OWASP El podcast de OWASP se descarga aquí , y es particularmente relevante en este contexto, blanco enumere sus datos aceptados (contenido xml), nunca incluya en la lista negra sus problemas conocidos con ese contenido.
Desactivar las referencias externas es genial (piense en alguien que esté leyendo su archivo / etc / passwd o / etc / shadow haciendo referencia a él usando el archivo: // protocolo en lugar del dtd).
Puede usar una resolución y un archivo de catálogo para controlar / reemplazar las referencias externas con copias locales válidas que no se pueden subvertir enlace
Puede usar un programa / biblioteca de validación extrínseca como el validador de múltiples esquemas de Sun / Oracle. enlace esto puede proporcionar validación incluso cuando no hay nada para validar internamente, y puede usar una tecnología diferente / complementaria como RELAX NG para validar su xml.
Tenga cuidado con todo tipo de inyección (SQL, Javascript, xmlns, imagen, svg, url, xslt, xpath, etc.), ya que pueden inyectarse y transmitirse a un contexto en el que se activan y se convierten en un peligro para su servidor db, servidor de aplicaciones o sus entornos de cliente. Considere una imagen codificada en base64 con un compromiso de 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.
El riesgo principal de no verificar la sintaxis de su XML es un análisis no válido.
Si el software que lee el XML no puede manejar la entrada no válida, puede fallar, hacer algo inesperado, explotar espontáneamente (probablemente no), etc. Esas situaciones pueden provocar fallas de seguridad, pero si el software es lo suficientemente frágil como para no hacerlo. ser capaz de 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 la aplicación web (por ejemplo, inyección de SQL) no son atacados usando un 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 se generó automáticamente. Cualquiera que sea el proceso, la entrada en la aplicación en sí debe verificarla también.