我目前正在开发一个WCF服务,该服务基于HTTP GET请求返回一个文件。该服务的主要概念如下:
public Stream MyGetMethod()
{
// Fetch the file
byte[] myFile = FetchMyFile();
// Set the name of the file using Content-Disposition
WebOperationContext.Current.OutgoingResponse
.Headers.Add("Content-Disposition", "attachment; filename=MyFile");
// Return the file
return new MemoryStream(myFile);
}
我使用Content-Disposition
头告诉浏览器,它应该将文件命名为MyFile
,并且应该显示"另存为"对话框(attachment
部分)。
在这个过程中,我读到了一些关于Content-Disposition
的不好的东西。
RFC2616状态:
RFC 1806[35],从中派生出HTTP中经常实现的Content-Disposition(见第19.5.1节)标头,有许多非常重要的安全考虑因素Content Disposition不是HTTP标准的一部分,但由于它得到了广泛的实现,我们正在为实现者记录它的使用和风险。有关详细信息,请参阅RFC 2183[49](更新了RFC 1806)。
从RFC2183我得到:
由于此备忘录为发件人提供了一种建议文件名的方式,
接收MUA必须注意发件人建议的文件名
不代表危险。以UNIX为例,一些危险
将是:
- 创建启动文件(例如".login")
- 创建或覆盖系统文件(例如"/etc/passwd")
- 覆盖任何现有文件
- 将可执行文件放入任何命令搜索路径(例如,"~/bin/more")
将文件发送到管道(例如"|sh")。
通常,接收MUA不应命名或放置文件以便在没有用户的情况下进行解释或执行明确地启动动作。
我看到这里面有一些严重的安全问题,但我不太确定这是否会阻止我使用它,就像上面的WCF服务一样?
在我看来,我认为这应该没问题,因为所有主要的浏览器都理解标题,虽然上面片段中的代码很简单,但我看不出这怎么会成为安全威胁?如果我错了,请纠正我。
谢谢。
使用Content-Disposition
是安全的,为了额外的安全性,不允许用户提供文件名,或者自己添加一些随机的唯一名称前缀或sufix或文件扩展名。