我以下代码中的路径遍历漏洞是否可能?
谁能确认,在我的下面代码段中,路径遍历漏洞是否可能?如果是,那么我应该做的改变。
[RedirectingAction]
public ActionResult Download(string fileName)
{
byte[] fileBytes = System.IO.File.ReadAllBytes(Server.MapPath("~/ClientDocument/") + fileName);
return File(fileBytes, System.Net.Mime.MediaTypeNames.Application.Octet, fileName);
}
Can anyone please confirm, is Path Traversal Vulnerabilities is possible in my below code snippet? if yes then what changes I should make.
[RedirectingAction]
public ActionResult Download(string fileName)
{
byte[] fileBytes = System.IO.File.ReadAllBytes(Server.MapPath("~/ClientDocument/") + fileName);
return File(fileBytes, System.Net.Mime.MediaTypeNames.Application.Octet, fileName);
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
是的,这很脆弱。
只是为了证明这一点,我设置了一个新的MVC项目,称为
webapplication1.sln
以下请求下载解决方案文件:
您可以编写一份幼稚的检查:
它将检查
file> file> fileName
参数是有效的文件名。此不包括目录分离器字符,因此它们不能以文件名的路径传递。但是,完全安全的唯一方法是限制您的应用程序的权限。仅将其许可授予您的虚拟目录,而别无其他。
Yes, it is vulnerable.
Just to prove it, I set up a new MVC project called
WebApplication1.sln
The following request downloads the solution file:
You can write a naive check:
Which will check that the
fileName
argument is a valid file name. This excludes directory separator characters, so they cannot pass a path as a filename.However, the only way to be completely safe, is to restrict the permissions your application has. Only grant it permission to your virtual directory, and nothing else.
从概念上讲,您应该采取的措施来减轻遍历轨道脆弱性的方法是将您的基地评估到其真实的道路上,同样对Basepath和FileName做同样的事情。如果第二个操作的结果文件仍在基地的文件夹内,则您知道尚未发生路径遍历。
我使用的是.NET的更晚版本SO so server.mappath无效。结果,我不确定这是否会为您服务;但这至少说明了如何在概念中解决它:
In concept what you should do to alleviate a Path Traversal vulnerability is to evaluate your basePath to its real path, and likewise do the same to your basePath plus the fileName. If the resulting file of the second operation is still within the folder from your basePath, you know that Path Traversial has not taken place.
I'm using a much later version of .NET so Server.MapPath is not valid. As a result, I'm not sure if this will run for you; but this at least demonstrates how to fix it in concept: