asp.net - mvc - render partial asp net core

¿A dónde va un archivo cargado en ASP.Net 2?

Question

Estoy construyendo un portal que permitirá a los usuarios subir archivos. Necesito asegurarme de que estos archivos no contengan virus. Mi solución ideal sería que el sistema operativo AV de host vigile las carpetas temporales y escanee cualquier archivo entrante.

Cuando se carga un archivo en ASP.Net 2, ¿se escribe en el disco en una carpeta temporal o persiste en la memoria? Si está escrito en el disco, ¿IIS lo bloqueará para que el AV no pueda eliminarlo? Y si está escrito en el disco, ¿dónde?

Answer 1

¿Estás usando el control de servidor ASP FileUpload?

Si es así, se carga en la memoria del servidor hasta que hagas algo con ella.

Esto es de MSDN;

No existe una limitación inherente sobre dónde puede guardar los archivos cargados. Sin embargo, para guardar el archivo, el proceso ASP.NET debe tener permiso para crear archivos en la ubicación que especifique. Además, su aplicación puede estar configurada para requerir una ruta absoluta (no una ruta relativa) para guardar el archivo, que es una medida de seguridad.

Answer 2

Creo que lo ideal sería tener una carpeta "Incoming" a la que se le hayan otorgado los permisos necesarios para que ASP.NET pueda guardar los archivos. Nunca me encontré con una situación en la que los archivos permanecen bloqueados incluso después de llamar a SaveAs en el control FileUpload.

Tenga en cuenta que el control FileUpload no carga el archivo hasta que no llame a SaveAs y esto es cuando el archivo se conserva en el disco del servidor. Parece contener todos los contenidos del archivo en un HttpInputStream , que se escribe en el disco cuando se SaveAs método SaveAs .

El archivo (s) debe ser libre para ser escaneado por su aplicación AV. En caso de que se produzca un error, puede proporcionar comentarios relevantes al usuario.

Answer 3

Al igual que Cerebrus, le diré que el control UploadFile NO escribirá nada en la unidad de disco a menos que se lo indique.

Answer 4

Si se toma en serio la seguridad, otro consejo relacionado es asegurarse de que la carpeta en la que está guardando los archivos esté por encima de la raíz web, de modo que los usuarios no puedan acceder directamente a ella de ninguna manera. Todavía puede darles la posibilidad de eliminar sus archivos cargados con algún trabajo de base de datos, es decir, guardar la ubicación y asegurarse de que cada archivo tenga un nombre único (si los usuarios se autentican, solo guardo el nombre de archivo como USERNAME.XYZ donde XYZ es la extensión del archivo) .

Answer 5

Para su situación ... Normalmente tengo una aplicación para cualquier ubicación de carga / temperatura, con un valor predeterminado en ~ / Datos_de_aplicaciones / Cargas / No debería estar visible para el AV hasta que los bytes se conserven en el disco. Si realmente desea un escaneo activo, entonces puede desear tener una cola de varias etapas ... (también, querrá hacer una solicitud de Async en ASP.Net), si espera a que se complete cualquier escaneo.

• Empuja el elemento en una cola para que se registre, digamos 30 segundos (tiempo suficiente para el escáner AV)
• Guarda el archivo en un directorio de carga (que se marca)
• Tiene otra verificación de servicio en la cola y la marca como completa / procesada si aún existe en 30 segundos
• Su UI comprobará la cola cada 10 segundos para ver si está lista, y luego la presentará al usuario.

Consideraría una lista blanca de su ruta de carga con su escáner nativo y veré si hay una API expuesta para ejecutar un escaneo manual a pedido. Una alternativa sería usar la configuración de ClamAV / ClamWin como un escáner de servicio, puede ejecutar actualizaciones cada hora (lo he hecho para sistemas de correo), y tiende a ser bastante decente con firmas de archivos, incluso en archivos de almacenamiento ( si está configurado correctamente).

Además, es posible que desee utilizar 7z.exe (línea de comando 7-zip) para extraer los archivos. 7-zip puede extraer casi todos los tipos de archivos que he visto, aunque solo admite un par de objetivos de compresión para nuevos archivos.

Espero que esto ayude, ya que iba a agregar esto como un comentario a otra publicación, pero se estaba haciendo muy largo.

Answer 6

Aquí está la suciedad real sobre cómo ASP.NET maneja los archivos. Es dependiente de la versión, pero 2.0 y todas las versiones posteriores escriben las cargas en el disco antes de que tenga la oportunidad de manejarlas. Las respuestas anteriores son realmente incorrectas: ASP.NET por encima de 2.0 escribirá el archivo en el disco. Si lo piensas bien, cargar una carga en la memoria te abre a un agujero DDOS ya que los archivos grandes ocuparían cantidades cada vez mayores de memoria del servidor. Por versión, así es como actúa ASP.NET:

• ASP.NET 1.0 y 1.1 cargaron toda la solicitud en la memoria antes de poder acceder a ella. Esto significaba que los archivos de gran tamaño podrían llenar toda la memoria, ocasionar excepciones y de otra manera derribar el servidor.

• ASP.NET 2.0 introdujo un esquema de almacenamiento en caché de disco para las cargas, volviendo a enganchar la carga y procesándola antes de que el código del cliente pueda manejarla. Se puede acceder a la carpeta temporal de la siguiente manera:

  string uploadFolder = Path.Combine (HttpRuntime.CodegenDirInternal, "cargas");

• A partir de ASP.NET 4.0, el nombre de propiedad al que se hace referencia más arriba es HttpRuntime.CodegenDir:

  string uploadFolder = Path.Combine (HttpRuntime.CodegenDir, "cargas");

Al menos ahora está en caché en el disco, por lo que no tiene problemas de memoria desde 1.0 y 1.1, pero aún no puede acceder hasta que se haya recuperado por completo.