为了详细说明这一点，我想知道具有以下配置的 IIS 网站上托管的文档的安全性如何：
- IIS 目录列表已禁用
- 匿名访问是已启用
- 网站可通过以下方式访问仅限 HTTPS
- 文件具有很长且随机生成的名称（类似于 guid 加上其他字符）
我相信这是一个相对地安全设置（我知道它不如真正经过身份验证的访问那么安全。）我想知道我是否看到了这堵大墙，但它是否会被比我更有知识的人轻易绕过。
我想我正在寻找的是可以绕过我上面概述的设置的方法。
答案1
不安全。你依赖的是通过隐蔽性实现安全，这绝不是一个好主意。如果有人猜出了你的文件名（或者你的“随机”名称不够随机，有人看到一个名称后就能推断出名称是什么），他们就可以窃取文件。
话虽如此，安全级别可能适合你正在做的事情。如果不知道你的数据有多敏感，就不可能确定。
答案2
虽然大多数人不会公开承认，但许多网站都使用与您的类似方法设置。您基本上是使用文件名作为密码。任何知道密码的人都可以访问该文件，但除非在 IIS 中发现漏洞或使用其他旁道攻击，否则在不知道正确“密码”的情况下无法远程访问您的文件。
您提到使用 HTTPS，这意味着URL 将被加密并且无法通过数据包嗅探器看到。但是，任何收到 URL 的客户端都可以自由地与世界共享该 URL。如果 Google 掌握了您文件的链接，它们将立即公开（如果它们是 HTML/TXT/PDF/DOC 格式，即使缓存也是如此）。您可以尝试通过将 robot.txt 文件更改为禁止抓取但即使这样也无法保证这些文件不会被公开。
由于文件名是您唯一的访问控制机制，因此您应该确保它满足最低复杂性要求。我建议至少包含 10-20 个随机字符，这将限制暴力攻击的有效性。此外，您可能需要考虑定期更改文件名，就像您定期更改密码一样。此外，您可能希望调整文件夹上的本地 NTFS 文件权限，以防止除系统管理员和 IIS/ASP.NET 帐户之外的任何人访问该文件夹。
在这种情况下，您的文件将达到可接受的安全级别，但仍可能受到可以通过普通用户名/密码身份验证阻止的攻击。客户端的浏览器历史记录、工具栏和扩展程序等简单内容都可以访问他们访问的 URL，因此如果您的文件包含国家机密或受联邦保护的信息（医疗记录、信用卡号等），您可能需要增加一些安全性。