¿Es necesario tener filtros XSS cuando estoy guardando datos como XML?

Question

¿Es necesario tener filtros XSS cuando estoy guardando datos como XML?

#1 de inf3rno (1 votos)
#2 de p____h (0 votos)

2

Mi aplicación web toma configuraciones del usuario y las guarda en un archivo XML (no se hizo para detener XSS). La entrada está codificada en XML para que " , & ... y dichos caracteres no rompan la estructura XML.

Entonces, ¿es necesario tener otra capa de filtro XSS o esta forma de guardar los datos detiene automáticamente los ataques XSS?

Soy consciente del hecho de que este ataque depende de muchos otros factores, como la representación de la página web, pero permite limitar la discusión al siguiente fragmento de código, sin embargo, desde la forma en que voy a imprimir los datos muy De vez en cuando eres libre de modificar echo "<h1> Hello ".$name."</h1>" para mostrarme formas incorrectas de imprimir datos.

$data = $_POST['malicious_user_supplied_data'];
$xml_encoded_data = xml_encode($data);
write_to_xml_as($xml_encoded_data,"config.xml");

------ config.xml --------
<user>
   <name>&lt;script&gt;alert(&quot;BigBang&quot;)&lt;/script&gt;</name>
</user>
--------------------------    

$name = get_name("config.xml") // would return &lt;script&gt;alert(&quot;BigBang&quot;)&lt;/script&gt;

echo "<h1> Hello ".$name."</h1>" // which on the browser would print &lt;script&gt;alert(&quot;BigBang&quot;)&lt;/script&gt;

Por favor, muéstrame algunos ejemplos de trabajo donde el filtro XML anterior se puede romper, si hay alguno.

xss encoding xml

pregunta vikkyhacks 06.08.2014 - 14:10

fuente

2 respuestas

Lea otras preguntas en las etiquetas xss encoding xml

Protección básica de sitios web (XSS, inyección de SQL, hashing) Fórmula utilizada en escalas de riesgo cualitativas

score 1 · Answer 1

Prefiero usar JSON en lugar de XML. Es más fácil comprender cómo funciona el analizador y, por lo tanto, los riesgos de seguridad son mucho menores. Por ejemplo, debes desactivar la carga de entidades externas con libxml_disable_entity_loader(true) si no quieres un ataque XXE, y así sucesivamente.

La otra parte de la pregunta es la generación de HTML, SVG, etc. en el navegador. Por ejemplo, con innerHTML = "..." es fácil inyectar javascript. Con las etiquetas data es posible inyectar javascript en firefox, por lo que no basta con filtrar solo las etiquetas script ... Debe usar siempre las funciones DOM como createTextNode() en lugar de innerHTML . No necesita un almacenamiento del lado del servidor para inyectar javascript. Mostrar parámetros de cookies o consultas usando javascript es más que suficiente. En el lado del servidor, también tienes que usar las funciones DOM, no estoy seguro de qué tan seguras son realmente, pero son mucho mejores que concatenar cadenas ... Ofc. tienes que filtrar por elementos HTML, etc. Pero si necesitas un editor de texto enriquecido, tienes un gran problema ...

Creo que una capa de seguridad nunca es suficiente, y en este caso ciertamente no es suficiente. Esto se debe a que los analizadores HTML son una tecnología muy compleja, y la mayoría de los desarrolladores (incluyéndome a mí) solo entienden los conceptos básicos de ellos. Lo que realmente necesita en este caso son algunos encabezados de seguridad , como Content-Security-Policy . Por lo tanto, el script inyectado no podrá comunicarse con el dominio del atacante. (Por ejemplo, esto no funciona en navegadores antiguos como ie6).

score 0 · Answer 2

Es difícil decirlo, si el código anterior está completamente protegido, ya que no nos proporcionó la definición de la función xml_encode . Basándose en sus muestras de entrada / salida, parece que xml_encode es similar a htmlspecialchars que podría usarse para sanear sus datos XML también.

Si fuera tú, decidiría usar htmlspecialchars con las marcas correctas ( ENT_QUOTES ) o las bibliotecas para crear documentos XML (por ejemplo, DOMDocument::createTextNode hará la codificación por ti).

Como no hay una definición de función xml_encode , juguemos con adivinanzas de caja negra, lo que podría salir mal aquí.

Codificación incorrecta: Debe asegurarse de que la aplicación web establezca el conjunto de caracteres correcto (por ejemplo, UTF-8). De lo contrario, su aplicación web podría ser vulnerable a los ataques XSS UTF-7. Este problema solo afecta a los navegadores antiguos.
Caracteres UTF-8: ¿ xml_encode codifica los caracteres UTF-8? ¿Cómo se muestran después del proceso de codificación?
sección CDATA: Este podría ser el complicado, si su xml_encode ignora las secciones CDATA. Estas secciones informan al analizador, que no hay marcas en los caracteres dentro de CDATA. Debe asegurarse de que < > " & también esté codificado dentro de CDATA.
Apóstrofe único: ¿Se codifica también el apóstrofo simple? Si no es así, debe tener cuidado al visualizar los datos de XML. %código%. El ejemplo anterior muestra que el código vulnerable, como atacante, podría inyectar <input type='text' value='<?php echo get_name("config.xml"); ?>' /> como su carga útil.
Nombres de etiquetas: ¿Está planeando permitir que el usuario también controle los nombres de etiquetas? En caso afirmativo, debe tener en cuenta que existe la posibilidad de realizar XSS directamente desde el archivo .xml. Mire aquí .