ASP.Net 2 中上传的文件去了哪里？
我正在构建一个允许用户上传文件的门户。 我需要确保这些文件不包含病毒。 我理想的解决方案是让主机操作系统 AV 监视临时文件夹并扫描任何传入的文件。
当文件上传到 ASP.Net 2 中时，它是写入磁盘的临时文件夹中，还是保留在内存中？ 如果写入磁盘，IIS 会锁定它，使 AV 无法删除它吗？ 如果写入磁盘，又写入哪里？
I'm building a portal that will allow users to upload files. I need to make sure that these files do not contain viruses. My ideal solution would be to have the host OS AV keep a watch on temporary folders and scan any incoming files.
When a file is uploaded in ASP.Net 2, does it get written to disk in a temp folder, or is it persisted in memory? If it is written to disk, will IIS lock it so that the AV cannot remove it? And if it is written to disk, where?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
就像 Cerebrus 一样，我会告诉您，UploadFile 控件不会将任何内容写入磁盘驱动器，除非您告诉它。
Just like Cerebrus I will tell you that the UploadFile control will NOT write anything to the disk drive unless you tell it to.
下面是 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 中的内存问题，但在完全检索它之前您仍然无法访问它。
Here's the actual dirt on how ASP.NET handles files. It's version dependant, but 2.0 and all subsequent versions do write uploads to disk before you get a chance to handle them. The above answers are actually wrong -- ASP.NET above 2.0 will write the file to disk. If you think about it, loading an upload into memory opens you to a DDOS hole as large files would take up increasing amounts of server memory. By version, here's how ASP.NET acts:
ASP.NET 1.0 and 1.1 loaded the whole request in memory before you could access it. This meant that large files could potentially fill all memory, causing exceptions and otherwise bringing down the server.
ASP.NET 2.0 introduced a disk caching scheme for uploads, again snagging the upload and processing it before client code can handle it. The temporary folder can be accessed as follows:
string uploadFolder = Path.Combine(HttpRuntime.CodegenDirInternal, "uploads");
As of ASP.NET 4.0, the property name referenced above is HttpRuntime.CodegenDir:
string uploadFolder = Path.Combine(HttpRuntime.CodegenDir, "uploads");
At least now it's cached to disk so you don't have the memory issues from 1.0 and 1.1, but you still can't access it until it's been fully retrieved.
我认为理想的方法是拥有一个“传入”文件夹，该文件夹已被授予 ASP.NET 保存文件所需的权限。 我从未遇到过即使在 FileUpload 控件上调用
SaveAs之后文件仍保持锁定状态的情况。请注意，在调用 SaveAs 之前，FileUpload 控件不会上传文件，此时文件将保存到服务器上的磁盘上。 它似乎将所有文件内容保存在
HttpInputStream中，当调用SaveAs方法时将其写入磁盘。然后，您的 AV 应用程序就可以自由扫描该文件。 如果出现错误，可以向用户反馈相关信息。
I think the ideal way would be have an "Incoming" folder that has been given the necessary permissions for ASP.NET to save files. I have never encountered a situation where files remain locked even after you call
SaveAson the FileUpload control.Note that the FileUpload control does not upload the file until you call
SaveAsand this is when the file is persisted to disk on the server. It seems to hold all file contents in anHttpInputStream, which is written to disk when theSaveAsmethod is called.The file(s) should then be free to be scanned by your AV application. In case an error occurs, you can give relevant feedback to the user.
您是否使用 ASP FileUpload 服务器控件？
如果是这样，它将被加载到服务器内存中，直到您对其执行某些操作。
这是来自MSDN；
Are you using the ASP FileUpload server control?
If so it is loaded into the servers memory until you do something with it.
This is from MSDN;
如果您认真对待安全性，另一个相关提示是确保您要保存文件的文件夹位于 Webroot 之上，以便用户无法以任何方式直接访问它。 您仍然可以让他们能够通过一些数据库工作来删除上传的文件，即保存位置并确保每个文件的名称都是唯一的（如果用户正在进行身份验证，我只需将文件名保存为 USERNAME.XYZ，其中 XYZ 是文件的扩展名。
If you're serious about security, another related tip is to make certain the folder that you're saving files to is above the webroot so users cannot directly access it in any way. You can still give them the ability to delete their uploaded files with some database work, i.e. save the location and make sure each file is uniquely named (if the users are authenticating I just save the filename as USERNAME.XYZ where XYZ is the file's extension.
对于您的场景...我通常有一个用于任何上传/临时位置的应用程序设置，默认值位于 ~/App_Data/Uploads/ 下，在字节持久保存到磁盘之前，它不应该对 AV 可见。 如果您确实想要主动扫描，那么您可能希望有一个多级队列...（另外，您将希望在 ASP.Net 中执行异步请求），如果您等待任何扫描完成。
我会考虑使用本机扫描仪将您的上传路径列入白名单，并查看是否有公开的 API 可以根据请求运行手动扫描。 另一种方法是使用 ClamAV/ClamWin 设置作为服务扫描器，您可以每小时对其运行更新（我已经为邮件系统执行了此操作），并且它对于文件签名往往相当不错，即使在存档文件中也是如此（如果配置正确）。
另外，您可能希望使用 7z.exe（7-zip 命令行）来提取任何存档。 7-zip 可以提取我见过的几乎所有存档类型，尽管它只支持新存档的几个压缩目标。
希望这会有所帮助，因为我打算将其作为评论附加到另一篇文章中，但它变得很长。
For your scenario... I usually have an appsetting for any upload/temp location, with a default under ~/App_Data/Uploads/ It shouldn't be visible to the AV until the bytes are persisted to disk. If you really want active scanning, then you may wish to have a multi-stage queue... (also, you will want to do an Async request in ASP.Net), if you wait for any scan to complete.
I would consider white-listing your upload path with your native scanner, and see if there's an API exposed to run a manual scan on-request. An alternative would be to use ClamAV/ClamWin setup as a service scanner, you can run updates on it every hour (I've done this for mail systems), and it tends to be fairly decent with file signatures, even in archive files (if configured properly).
Also, you may wish to use 7z.exe (7-zip command line) to extract any archives. 7-zip can extract just about every archive type I've seen, even though it only supports a couple of compression targets for new archives.
Hopefully this helps as I was going to append this as a comment to another post, but it was getting lengthy.