¿Alguna vulnerabilidad al permitir que los usuarios elijan la ruta del archivo S3?

Question

¿Alguna vulnerabilidad al permitir que los usuarios elijan la ruta del archivo S3?

#1 de SilverlightFox (1 votos)
#2 de Ayrx (0 votos)

1

Estoy creando una aplicación web que utiliza S3. En algunas de nuestras operaciones, estamos creando un archivo en S3 con una ruta que depende directamente de la entrada del usuario, por lo que un atacante podría crear un archivo en S3 con la ruta que quiera.

¿Hay una forma para que un atacante aproveche esto en un ataque? (Algunas ideas que me vinieron a la mente fueron usar nombres de archivos mágicos o alimentar caminos muy largos, pero si tienes otras ideas, me encantaría escucharlas).

Si existe una posibilidad seria de vulnerabilidad, consideraremos rediseñar el sistema.

web-application path-injection

pregunta Ram Rachum 24.02.2014 - 12:16

fuente

2 respuestas

0

Sin realmente sumergirte en la API de S3, aquí hay algunas posibilidades.

¿Puede el usuario sobrescribir archivos si conoce la ruta?
¿Puede el usuario leer archivos si conoce la ruta?
¿Puede el usuario enumerar archivos existentes? Esto podría ser un problema si se supone que los archivos son privados.

No es nada que tu aplicación no pueda manejar con una pequeña cantidad de código, pero tienes que pensar realmente en los casos de borde.

respondido por el Ayrx 24.02.2014 - 13:02

fuente

Lea otras preguntas en las etiquetas web-application path-injection

¿Qué tipos de ataques de hacking ocurren junto con un ataque de DOS o DDOS? [cerrado] ¿Administración de claves en proxies de intercepción?

score 1 · Accepted Answer

Las dos posibles vulnerabilidades que vienen a la mente son Path Traversal y XSS .

Para protegerse contra Path Traversal, valide la entrada de la ruta para asegurarse de que el usuario no pueda cambiarla para incluir caracteres como .. o / o sus versiones codificadas (por ejemplo, %2e%2e ). Si pudieran, existe la posibilidad de que su aplicación (o la API de S3) interpretara que los caracteres son la carpeta principal o raíz.

Por ejemplo, si el usuario estaba guardando en S3 en su carpeta /foo y estableció su nombre de carpeta en ../bar/ , debería asegurarse de que el archivo no esté guardado en /bar en su lugar (que puede ser la carpeta de otro usuario ).

XSS es solo un problema si el dominio se comparte con cualquier código de aplicación que use cookies. Es poco probable en este escenario, pero pensé que lo mencionaría por si acaso. Esto también se aplicaría solo si el usuario pudiera influir en el contenido del archivo, como por ejemplo, poder incluir las etiquetas <script> y luego hacer referencia a la página como un documento HTML que el usuario podría visitar y que luego transmitiría cookies al atacante.