XXE y su impacto

3

Estoy tratando de entender el concepto detrás de XXE (inyección de entidad externa XML). Pasé por Pautas de OWASP sobre XXE

Y como soy nuevo en XML y DTD, también estudié los tutoriales de W3Cschools sobre estos temas. Ahora, de acuerdo con mis lecturas, intenté crear una demo de XXE. Así que abajo está mi intento de hacer lo mismo: -

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE note [
<!ELEMENT note (to,from,heading,body,author)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
<!ENTITY writer "Donald Duck.">
<!ENTITY copyright "Copyright W3Schools">
<!ENTITY attack SYSTEM "file:///Users/testuser/Desktop/BB/demos/test.txt">
]>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend</body>
<author>&writer;&copyright;&attack;</author> 
</note> 

Y en el camino

  

file: /// Users / testuser / Desktop / BB / demos /

Tengo un archivo test.txt que contiene una cadena, por ejemplo: -

  

esto es algo secreto

Ahora, cuando abro mi archivo XML en Firefox, me da la estructura de árbol de mi documento XML y, como se esperaba, expande el escritor y el copyright de las entidades con su contenido respectivo tal como se define en la DTD. Sin embargo, el analizador XML no expandió la "ataque" de la entidad, lo que debería haber ocurrido como se ha demostrado en el enlace anterior.

Ahora me gustaría saber por qué no se expandió el ataque de la entidad. Y en segundo lugar, incluso si se expandiera, ¿no entrarán en juego aquí los permisos de archivo (del sistema de archivos local)?

    
pregunta qre0ct 05.01.2014 - 13:04
fuente

2 respuestas

2

Solo para completar esto un poco más allá de su punto original sobre los navegadores.

Por lo general, XXE es un ataque en el lado del servidor, por lo que un usuario que visita el sitio puede obtener acceso a los archivos fuera de webroot, a los que normalmente no tendrían acceso.

El acceso y el impacto de la XXE dependen de si el atacante puede encontrar archivos útiles y también los permisos del usuario que ejecuta la aplicación web. El tipo de cosas que podrían resultar particularmente problemáticas son los archivos de configuración en ubicaciones predecibles que contienen nombres de usuario / contraseñas que le permiten al atacante obtener acceso adicional (por ejemplo, un archivo que proporciona credenciales para una aplicación de administración)

También existe la posibilidad teórica de convertir esto en inclusión de archivos remotos como la especificación. admite el concepto de una entidad externa remota (es decir, retira el contenido de un archivo de un servidor remoto y los procesa en el documento), pero nunca lo he visto implementado en la práctica.

En términos de mitigación, esto generalmente se realiza a nivel del analizador XML y la solución más sencilla es deshabilitar la expansión de la entidad, a menos que se requiera específicamente para el funcionamiento de la aplicación (rara vez es un requisito de lo que he visto) . Si es necesario, es probable que la validación / codificación de entrada sea el enfoque correcto para solucionarlo.

    
respondido por el Rоry McCune 05.01.2014 - 14:54
fuente
2

Si está ejecutando Linux, hay un analizador XML, xmllint. Puede usarlo para analizar documentos xml y para expandir las referencias de entidades use la opción --noent.
Por ejemplo:

xmllint --noent xxe.xml

Y, yes . El permiso de archivo entra en juego. Si no tiene suficiente permiso para leer el archivo, encontrará un error.

Por ejemplo, suponiendo que está en una máquina Linux, si reemplaza
file: ///Users/testuser/Desktop/BB/demos/test.txt
con
archivo: /// etc / shadow ¿Te equivocas? Luego, puede ejecutar el comando anterior con sudo para obtener el contenido del archivo etc / shadow .

Espero que ayude, al menos a otros que puedan visitar esto :)

    
respondido por el 1lastBr3ath 05.05.2015 - 16:05
fuente

Lea otras preguntas en las etiquetas