Zona de juegos pública XSLT y XML (con PHP DOMDocument, etc.) ¿Riesgos de seguridad?

Soy un 'novato' de PHP, si me puedes llamar uno. Pero habiendo analizado las bibliotecas XML y XSLT en el pasado en busca de vulnerabilidades de seguridad, y habiendo trabajado recientemente en una aplicación que usa bastante XML, esto es lo que podría pensar:

• Si es posible pasar una transformación XSL que cause la ejecución de un código privilegiado, es posible que tenga que encontrar algún medio para deshabilitar dicha ejecución. En el mundo Java (de donde vengo), esta 'característica' no es un estándar, pero puede encontrarla implementada en Transformador Xalan-J, donde se han construido varias extensiones . Si un atacante pasara un archivo XSL, que intentara ejecutar una consulta SQL (usando la extensión SQL), o ejecutara un código ya disponible en el servidor (usando la extensión Java), entonces Xalan-J lo haría, si las condiciones tenían razón. No estoy seguro de si esto se aplica a los transformadores utilizados por PHP, pero vale la pena asegurarse de que el transformador transforme XML en XML y no realice nada más (lo que parece ser su requisito). Reitero esto en palabras más simples como: elija un transformador XML que se pueda bloquear tanto como sea posible, para proporcionar solo la función necesaria de transformación de documentos XML.
• Los archivos y otros URI (que no son visibles para el atacante) se pueden especificar en el XSL, que será recuperado por el transformador y podría incluirse en el XML resultante. Este es el ataque de expansión de entidad externa (XXE). Sería posible obtener /etc/passwd , /etc/shadow etc. de esta manera, si los archivos fueran accesibles al proceso subyacente. Deshabilite la expansión de las referencias de entidades, si puede.
• Relacionado con XXE, es XDoS que permite montar ataques de denegación de servicio, Consumo resultante de ciclos de CPU. Las contramedidas incluyen:
  • que limita el número de expansiones de entidades que puede realizar el analizador (que es similar a la proceso seguro) soporte requerido por la API de Java para XML Processing 1.4). Una contramedida relacionada en esta área es limitar el número de atributos que pueden aparecer en cualquier elemento del documento.
  • deshabilita el uso de DTDs; su analizador debe estar configurado para rechazar cualquier documento con un elemento DOCTYPE. Este es el enfoque adoptado por las implementaciones de SOAP.
• También existe la posibilidad de que XSS se refleje (suponiendo que no esté rellenando el área de texto usando JavaScript), ya que las transformaciones XSL no necesitan generar XML o HTML válidos. El resultado podría ser simplemente cualquier secuencia aleatoria de caracteres. Por lo tanto, la salida debería escaparse adecuadamente para evitar cualquier ataque XSS.
• Las vulnerabilidades en el analizador XML en sí harán posibles otras formas de ataques. Este aviso del CERT , es un póster, ya que es indicativo de los posibles problemas en XML analizando bibliotecas. Los analizadores son complejos, debido a los diversos requisitos que se les imponen a través de diversas especificaciones; a veces esto resulta en casos extremos donde los analizadores no podrían manejar ciertas secuencias de caracteres de manera segura. Aunque se ha realizado bastante trabajo para escribir analizadores seguros, el trabajo no puede considerarse no completo. La recomendación adecuada en este caso es elegir una biblioteca de análisis XML bien implementada y entendida, y parchear la biblioteca de análisis periódicamente para obtener soluciones de seguridad.

Lo anterior no es necesariamente exhaustivo, pero supongo que es un buen punto de partida.