XSS reflejado a través de $ _FILES

¡Bien! Encontré esta pregunta por accidente y quería compartir una información útil sobre cómo se puede explotar, en caso de que alguien todavía esté buscando una respuesta.

En resumen, es posible activar XSS reflejado en el fragmento de código que mencionó

echo $_FILES["file"]["name"];

La técnica depende de usar una forma de tipo multipart/form-data e inyectar la parte que incluye el nombre del archivo y el tipo como parte del nombre del campo como se explica en este artículo

Por ejemplo

<form method="post" action="http://example.com/uploadpage" enctype="multipart/form-data">
<textarea name='file"; filename="<svg onload=alert(document.domain)>
Content-Type: text/plain; '>Arbitrary File
Contents</textarea>
<input type="submit" value='Send "File"' />
</form>
<script>document.forms[0].submit();</script>

Este fragmento de código explota la vulnerabilidad XSS reflejada sin la interacción del usuario.

• Probado en la última versión de Edge, IE (✓)

• Firefox agrega una barra invertida antes de las comillas, lo que hace que el nombre del campo se confunda.

• La url de Chrome codifica las comillas a% 22 por lo que esta técnica no funciona.

Cómo funciona

  

Se basa en un error en Firefox / IE / Safari, donde los nombres de archivo no se escapan antes de colocarlos en el cuerpo de la POST para establecer el parámetro de nombre de archivo y el encabezado de tipo de contenido.

Esto no es posible.

No es posible manipular un formulario HTML utilizando JavaScript en lo que respecta a los campos de carga de archivos. Como se indicó, el formulario debe enviarse como multipart/form-data y el nombre de archivo debe enviarse como parte de eso:

Content-Disposition: form-data; name="file"; filename="foo.exe"

El valor de una entrada con archivo de tipo es de solo lectura en JavaScript. Esto es para evitar que una página web maliciosa seleccione el archivo local de un usuario y lo cargue sin su conocimiento.

Construir la solicitud POST completa en JavaScript tampoco es una opción. Esto se debe a que la respuesta de la solicitud se recuperará como datos de JavaScript, no como una página visualizada como con un formulario HTML. Como notó, la Política del mismo origen evitará que la respuesta se lea de todos modos, pero esto no importa. Incluso si pudiera leerse, diga si CORS está habilitado y el JavaScript presenta la respuesta como HTML: este HTML y cualquier script malicioso se representarán en el origen del atacante, no el origen del sitio de destino donde se requiere la sesión de la víctima. Ser comprometido por el atacante.

El único ataque que viene a la mente es establecer el enctype de un formulario HTML en text/plain y tratar de construir el

Content-Disposition: form-data; name="file"; filename="foo.exe"

línea que usa una entrada oculta como lo hace para JSON . Sin embargo, esto no permitirá que se incluya el tipo de contenido y el límite correctos en el encabezado de la solicitud para el análisis correcto por PHP y fallará:

Content-Type: multipart/form-data; boundary=----WebKitFormBoundarykjwI5NtRzEheYJYc