上传的白名单或黑名单文件扩展名？
我正在制作一个新闻通讯编辑器，它将允许文件上传（新闻通讯的发件人可以将文件上传到将在电子邮件中链接到的服务器）。
该站点的设置使得只有 .do URI 实际由 servlet 执行/处理，因此不会有太大的安全风险，但有人告诉我将 .jsp、.php、.asp、.aspx、.exe 列入黑名单。 .com 和 .bat。我觉得这并不是一个全面的黑名单，而且我的印象是黑名单不是一个好政策。
另一方面，白名单可能有几十个长。识别允许/不允许的扩展的正确方法是什么？或者只允许任何内容并通过病毒扫描程序或这些的某种组合来运行它是否更合适？
I'm making a newsletter editor which will allow file uploads (the sender of the newsletter can upload files to the server which will be linked to in the email).
The site is set up so that only .do URIs are actually executed/handled by servlets so it's not much of a security risk, but I've been told to blacklist .jsp, .php, .asp, .aspx, .exe, .com, and .bat. This does not strike me as a comprehensive blacklist, and I've the impression that blacklists are not a good policy.
On the other hand, a whitelist would be dozens long. What's the correct way to identify allowable/disallowable extensions? Or is it more proper to just allow anything and run it by a virus scanner, or some combination of these?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我允许上传任何文件扩展名，但我会将文件存储在不直接由 Web 服务器提供服务的文件夹中。然后，我将创建一个从电子邮件链接到的 HTTP 处理程序，该处理程序将传输所请求的文件。可以通过原始文件名、系统生成的文件名或 ID 来请求文件。无论哪种方式，我都会清理参数以防止目录遍历攻击。
例如 www.example.com/FileLink.ashx?FileName=Word.docx
这样，您无需担心将来是否希望将其他文件扩展名作为可执行文件类型提供服务，因为任何文件都直接从字节流提供文件系统，并且永远不会通过 Web 服务器处理程序传递。
您还可以使用处理程序来检查当前用户是否具有加载文件的正确权限。
对每个文件进行病毒扫描也是值得的，以防时事通讯作者上传（恶意或意外）的文件攻击订阅者的计算机而不是服务器。
还要确保
Content-Disposition设置为attachment：这可以防止通过上传包含脚本标记的 HTML 或其他同源策略来实现 XSS 绕过 Flash 或 PDF 文件。这里的场景是一名新闻通讯编辑危及另一名新闻通讯编辑的会话。还值得设置 X-Content-Options: nosniff，这也可以防止这种情况。
xap文件 (Silverlight) 也可能绕过同源策略，因此请检查文件名是否不能以.xap结尾来请求您的文件，例如
www.example.com/FileLink.ashx/x.xap?FileName=Word.docx并且您可以将 Silverlight 的内容类型设置列入黑名单，作为针对这种特殊情况的额外保护。 来源此处：
我自己也验证了这些场景，它们是目前有效的攻击媒介。
I would allow any file extension to be uploaded, but I would store the files in a folder that is not directly served by the web server. I would then create a HTTP handler that would be linked to from the email, which would stream the requested file. The file could be requested either by original file name, a system generated file name or by an ID. Either way, I would sanitise the parameter to guard against directory traversal attacks.
e.g. www.example.com/FileLink.ashx?FileName=Word.docx
This way you do not need to worry if in future you wish to serve additional file extensions as executable file types, as any file is served directly from a byte stream from the file system and is never passed through the web server handlers.
You can also use the handler to check that the current user has the correct permissions to load the file.
It would also be worth virus scanning each file, just in case the newsletter author uploads (either maliciously or accidentally) a file that would attack subscribers' computers rather than the server.
Also ensure that the
Content-Dispositionis set toattachment:This guards against XSS being achieved by upload of HTML containing script tags, or other Same Origin Policy bypasses using Flash or PDF files. The scenario here is one newsletter editor compromising the session of another newsletter editor. It is worth also setting
X-Content-Options: nosniff, which can also protect against this.xapfiles (Silverlight) could also bypass the Same Origin Policy, so check that the filename cannot be ended in.xapto request your filee.g.
www.example.com/FileLink.ashx/x.xap?FileName=Word.docxand you could blacklist the setting the content type for Silverlight as extra protection for this special case. Source here:
I've also verified these scenarios myself and are are currently valid attack vectors.
是的。
黑名单和白名单都可以被轻易规避，只会给管理带来麻烦，而且不提供任何安全性。
Yes.
Both blacklists and whitelists are trivially circumvented and cause just administration pain and provide no security whatsoever.
在我看来，尽管白名单维护起来可能有点麻烦，但它比使用黑名单安全得多。
忘记将某些内容添加到白名单并不得不返回并更改它，比忘记将新的文件扩展名添加到黑名单并被黑客攻击要好得多。
除了白名单之外，我仍然会对上传的文件进行病毒扫描，因为即使是看似无害的文件（例如.pdf或.doc）也可能含有恶意代码（.pdf支持javascript和.doc宏）
In my opinion, even though the whitelist maybe a bit of a chore to maintain, it's far more secure than using a blacklist.
It's much better to forget to add something to the whitelist, and have to go back and change it, than to forget to add a new file extension to the blacklist and get hacked.
In addition to the whitelist, I would still virus scan the uploaded files, as even seemingly harmless files (such as .pdf or .doc) can have malicious code (.pdf's support javascript, and .doc macros)
我建议您：
更安全）
防病毒软件不值得。大多数 Web shell 签名确实很容易绕过，因为任何“黑客”都可以添加一些随机代码并在 Web shell 上执行不同类型的编码。当然，它会保护您免受 C99 等常见 shell 的侵害，但现在有数以千计的此类工具是公开可用的，并且完全无法检测到。关于保护您的用户免受网站上托管的可执行文件或受感染 PDF 的侵害，如果有人能够在您的网站上获取 shell 并启动恶意软件活动，那么它就不会使用防病毒签名已发现的恶意软件或病毒。
I would recommend you:
more secure)
Antivirus aren't worth it. Most of web shells signatures are really easy to bypass since any 'hacker' can add some random code and do different types of encodings on an web shell. Sure it will protect you from common shells such as C99 but nowadays there are thousands of these tools publicly available and fully undetectable. And regarding protecting your users from executable files or infected PDF's hosted on your websites, if someone it's capable of get a shell on your site and start up a malware campaign it won't use malware or virus already spotted by av signatures.