Где находится загруженный файл в ASP.Net 2?

Question

Я строю портал, который позволит пользователям загружать файлы. Мне нужно убедиться, что эти файлы не содержат вирусов. Моим идеальным решением было бы заставить AV AV операционной системы следить за временными папками и сканировать любые входящие файлы.

Когда файл загружается в ASP.Net 2, он записывается на диск во временную папку или сохраняется в памяти? Если он будет записан на диск, заблокирует ли его IIS, чтобы AV не мог его удалить? А если он записан на диск, где?

Answer 1

Вот фактическая грязь в том, как ASP.NET обрабатывает файлы. Это зависит от версии, но 2.0 и все последующие версии записывают загружаемые файлы на диск, прежде чем вы получите возможность обработать их. Приведенные выше ответы на самом деле неверны - ASP.NET выше 2.0 будет записывать файл на диск. Если вы подумаете об этом, загрузка загрузки в память откроет вам дыру в DDOS, поскольку большие файлы будут занимать все больше памяти сервера. В зависимости от версии, вот как работает ASP.NET:

• ASP.NET 1.0 и 1.1 загружали весь запрос в память, прежде чем вы могли получить к нему доступ. Это означало, что большие файлы могли потенциально заполнить всю память, вызывая исключения и в противном случае приводя к остановке сервера.

• ASP.NET 2.0 ввел схему кэширования диска для выгрузки, опять же выхватив загрузку и обработав ее, прежде чем код клиента сможет ее обработать. Доступ к временной папке можно получить следующим образом:

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

• Начиная с ASP.NET 4.0, упомянутое выше имя свойства - HttpRuntime.CodegenDir:

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

По крайней мере, теперь он кэшируется на диск, поэтому у вас нет проблем с памятью от 1.0 и 1.1, но вы все равно не можете получить к нему доступ, пока он не будет полностью восстановлен.

Answer 2

Я думаю, что идеальным способом было бы иметь папку «Входящие», которой были предоставлены необходимые разрешения для ASP.NET для сохранения файлов. Я никогда не сталкивался с ситуацией, когда файлы остаются заблокированными даже после вызова SaveAs в элементе управления FileUpload.

Обратите внимание, что элемент управления FileUpload не загружает файл до тех пор, пока вы не вызовете SaveAs, и это происходит, когда файл сохраняется на диске на сервере. Кажется, он хранит все содержимое файла в HttpInputStream, который записывается на диск при вызове метода SaveAs.

Файл (-ы) должны быть бесплатно отсканированы вашим AV-приложением. В случае возникновения ошибки, вы можете дать соответствующую обратную связь пользователю.

Answer 3

Вы используете серверный элемент управления ASP FileUpload?

Если это так, он загружается в память сервера до тех пор, пока вы с ним что-то не сделаете.

Это из MSDN;

Нет никаких ограничений на то, где вы можете сохранять загруженные файлы. Однако для сохранения файла процесс ASP.NET должен иметь разрешение на создание файлов в указанном вами месте. Кроме того, ваше приложение может быть настроено на использование абсолютного пути (не относительного пути) для сохранения файла, что является мерой безопасности.

Answer 4

Для вашего сценария ... Обычно у меня есть appsetting для любого местоположения загрузки / временного хранения, со значением по умолчанию в ~ / App_Data / Uploads / Оно не должно быть видимым для AV, пока байты не будут сохранены на диске. Если вы действительно хотите активное сканирование, то вы можете захотеть иметь многоэтапную очередь ... (также вы захотите сделать асинхронный запрос в ASP.Net), если вы ждете завершения любого сканирования.

• Вы помещаете элемент в очередь для проверки, скажем, 30 секунд (достаточно времени для AV-сканера)
• Вы сохраняете файл в каталоге загрузки (который проверяется)
• У вас есть другая проверка сервиса для очереди, и отметьте ее как завершенную / обработанную, если она все еще существует в течение 30 секунд
• Ваш пользовательский интерфейс будет проверять очередь каждые 10 секунд, чтобы узнать, сделано ли это, а затем представить ее пользователю.

Я бы посоветовал добавить в белый список ваш путь загрузки с вашим собственным сканером и посмотреть, есть ли API, доступный для запуска сканирования вручную по запросу. Альтернативой может быть использование установки ClamAV / ClamWin в качестве сервисного сканера, вы можете запускать обновления на нем каждый час (я делал это для почтовых систем), и он обычно довольно приличный с сигнатурами файлов, даже в архивных файлах ( если настроено правильно).

Также вы можете использовать 7z.exe (командная строка 7-zip) для распаковки любых архивов. 7-zip может извлекать практически все типы архивов, которые я видел, хотя он поддерживает только несколько целей сжатия для новых архивов.

Надеюсь, это поможет, поскольку я собирался добавить это в качестве комментария к другому сообщению, но оно становилось длиннее.

Answer 5

Если вы серьезно относитесь к безопасности, другой связанный с этим совет - убедиться, что папка, в которую вы сохраняете файлы, находится выше веб-корня, чтобы пользователи не могли напрямую получить к нему доступ. Вы по-прежнему можете дать им возможность удалять свои загруженные файлы с некоторой работой с базой данных, то есть сохранить местоположение и убедиться, что каждый файл имеет уникальное имя (если пользователи аутентифицируются, я просто сохраняю имя файла как USERNAME.XYZ, где XYZ - расширение файла .

Answer 6

Так же, как Cerebrus, я скажу вам, что элемент управления UploadFile будет НЕ записывать что-либо на диск, если вы не сообщите об этом.