保护HTTP引用程序

我开发的软件将文件存储在随机名称的目录中，以防止未经授权的用户下载文件

我们需要做的第一件事是将它们存储在单独的顶级域中（以防止cookie被盗）

第二个危险是HTTP referer，它可能会泄露机密目录的名称

我在Chrome浏览器上的实验表明，只有在我单击（机密）文件中的链接时，才会发送HTTP referer。因此，问题仅限于可能包含链接的文件（在Chrome HTML和PDF中）。对于所有浏览器，我是否可以依赖这种行为（如果下一页不是从当前（秘密）页面链接打开的，而是使用其他方法打开的，例如直接输入URL，则不发送referer）

因此，问题仅限于HTML和PDF文件。但这并不是一个完整的安全解决方案

我想，我们可以通过在提供所有机密文件时添加

内容处置：附件
来完全解决这个问题。它会阻止HTTP引用程序吗

还请注意，我将使用HTTPS来表示中间人无法下载我们的机密文件。
您可以使用标头来尝试控制引用者的行为。请注意，这需要

与其试图隐藏文件位置，我可以建议您实施正确的身份验证和授权处理吗？
我同意
参考者策略是您最好的第一步，但正如DaSourcerer所指出的，它并没有在您可能支持的浏览器上普遍实施

完整的服务器端解决方案如下所示：


用户连接到
../
服务器生成一次性令牌并重定向到
../
服务器提供文档并使令牌无效

现在，referer将指向不再有效的
../
。然而，这有可用性权衡：


重新加载页面将不起作用（尽管您可以通过cookie或会话解决此问题）
用户无法从URL栏共享URL，因为它在技术上是无效的（在某些情况下，这可能是一个小好处）

通过使用
IFRAME
而不是重定向，您可能可以获得相同的基本好处，而无需进行可用性权衡。我不确定IFRAME如何影响Referer

整个解决方案基本上都是主动完成的。如果您可以重写文档中的链接，那么您可以在退出时使用Referer屏蔽。（即重写所有链接，使其指向
https://yoursite.com/redirect/....
）既然您提到PDF，我想这将是一个挑战（或者您不想重写文档）。
为什么要使用真实路径？如果要保护文件，请将其存储在无法通过HTTP访问的位置，并通过脚本读取/返回这些文件，该脚本负责您所需的任何身份验证。如果你发现自己在担心推荐人，那么设计可能有问题。@AlexK。我这样做是为了让上传文件的用户通过只共享URLATA轻松共享它，而不是“适当”的认证和授权处理阻止共享文件的简单文件共享？请考虑<代码>。http://www.yoursite.com/a_long_unique_id/thefile.ext
-您的应用程序收到url，提取一个_long _unique _id在数据库中查找它以获取任何权限和实际磁盘路径，如果所有脚本都正常，则从其实际位置读取文件，然后将其写回客户端。可能。但是，如果通过HTTP方式进行身份验证，客户端可以缓存凭据。@AlexK建议的一次性链接。罗布·纳皮尔是一个可行的解决方案，但对我来说，他们有点太爱乐队了。您可能希望了解nginx’。祝你好运