说，我的服务器上有一个我想保密的页面或文件夹。
example.com/fdsafdsafdsfdsfdsafdrewrew.html
或
example.com/fdsafdsafdsfdsfdsafdrewrewaa34532543432/admin/index.html
如果路径的秘密部分很长，我可以假定拥有这样一个秘密页面或区域是安全的，并且很难猜测或强行使用它吗？
这种方法通常有什么问题？
请注意，我并不是在问如何正确执行此操作，但是这种方法有什么问题（如果有）。
/>
#1 楼
您实际上是在询问在GET请求中传递秘密参数是否安全。实际上，这被归类为漏洞。假设服务器仅在指定无效路径时仅返回静态404响应，否则强行强制使用足够长的伪随机字符串是不可行的，但是实践中还有许多其他安全问题使之成为危险技术：记录软件通常以纯文本记录GET请求，而不记录POST。
在处理活动内容时，使用GET会使CSRF变得轻而易举。
引用标头可能会将秘密值泄漏给其他网站。
浏览器历史记录将保留GET请求中传递的机密。
第二个示例中包含
/admin/。对我而言，这意味着仅通过此路径的知识就足以在管理员上下文中向服务器进行身份验证。这是非常不安全的，不应仅在主要的网络安全专家/?password=hunter2之前进行。相反，应在POST请求中发送机密信息。如果无法做到这一点，或者您的威胁模型是专门用于防止URL的强行使用（例如，密码重置链接在使用后立即失效），则应谨慎行事。我不知道有任何旁信道攻击会提供一种比蛮力更快地获取字符串的方法。
*避免参数化GET请求不会阻止CSRF攻击，这是一种常见的误解，因为滥用POST（伪造表单等）的方式多种多样，但是在GET中传递机密确实使CSRF更容易。
评论
“ CSRF成为一个问题。实际上，仅将POST用作机密可以缓解CSRF。”如您在链接的OWASP文章中所述，这实际上并不能阻止CSRF。
–亚历山大·奥玛拉（Alexander O'Mara）
18年6月19日在5:30
@Kargari因为服务器不会告诉您猜测字符串的距离。如果输入错误的字符串，则无论关闭1个字符还是关闭50个字符，它都会返回404。因此，您将必须穷举所有可能的字符串，直到完全正确为止。无论如何，我可能应该说不可行而不是不可能。现在进行编辑。
–森林
18 Jun 19'在6:29
定时攻击可能是可能的；我怀疑网络服务器和操作系统在检查路径是否存在时会使用固定时间比较！
–user371366
18年6月19日在7:14
@Kargari蛮力非常非常慢。对于30个字符的字母数字字符串（即a-z，A-Z和0-9），您有62 ^ 30种可能的组合，这远远超出了今天的组合。
–森林
18年6月19日在9:01
您可以通过存储随机字符串的散列来减轻这种定时攻击。因此，时间会告诉您散列匹配的字符数，但这与原始字符串匹配的字符数无关。
– Barmar
18年6月19日在17:19
#2 楼
这是共享仅限于知道URL的公共内容的通用方法。一个示例是Google文档：
第二个选项“知道链接的任何人”都会创建一个与您相似的链接。与Google Photos，Dropbox，...相同。
优点是内容的传播受到限制。
缺点是这在某种程度上取决于您与谁共享链接，发布位置等。
您应该考虑的一件事是很容易使它无效（通过更改/重新生成数据链接）
评论
这也是“取消订阅”链接的常用机制。
–米卡（Micah）Epps
18年6月20日在18:48
该答案引用了Google文档，但是（正确地）提到文档直到所有者决定共享链接时，它才创建链接。这与创建内容的那一刻起就有一个链接不同，例如在OP中。我不能强行强制任意用户的私人文档，只有他们故意为其建立公共链接的那些文档。
– Knetic
18年6月22日在5:22
我还要补充一点，就是Google对几乎每个人（或至少每个浏览器；拥有或不拥有Google帐户都没有关系，每个拥有浏览器的人都拥有Google内部帐户）具有广泛的知识，他们可能会在后台使用它在授予或拒绝通过唯一链接访问可用文档时。问题是，OP是否有类似的数据和工具可供使用。
–帕维尔
18年6月22日在7:17
@Pavel：我不确定我是否理解。您的意思是“使用浏览器的每个人都拥有Google内部帐户”？通过授予或拒绝通过唯一链接访问的文档时，他们可以在后台利用它？
– WoJ
18年6月22日在7:23
@WoJ Google会积极跟踪浏览器及其用户（Analytics，标签管理器，API，字体，reCaptcha，8.8.8.8等在整个网络中使用率很高），因此当您的浏览器通过唯一URI请求文档时，Google已经知道超出您的意愿（当然，跟踪唯一的Docs链接的生命是同一故事的一部分）。这使得挑战甚至过滤掉犯规球员变得容易。
–帕维尔
18年6月22日在9:44
#3 楼
馊主意。我多次看到“秘密” URL很快就吸引了搜索引擎爬虫命中，然后可以通过网络搜索发现。我什至看到有人在他的域的子文件夹中建立了一个信誉良好的网站的副本，与一个人共享，然后他很快收到了一封电子邮件通知，警告他，他的域可能已被用于网络钓鱼目的。这是怎么发生的？在后一种情况下，Web浏览器具有内置的反网络钓鱼功能，该功能将访问的URL发送给欺诈检测服务。在其他情况下，也许浏览器正在收集浏览数据并将其发送到搜索引擎以收集用户习惯。
如果这样做，请确保您的robots.txt（或标头/元标记）设置为告诉搜索引擎不要为内容建立索引。
互联网是使世界紧密联系的一种绝妙方法，但是不幸的是，它使每个人都可以永久访问您碰到的任何东西。
评论
引擎不索引内容。 ->是否不通过将其网址添加到robots.txt中来索引我的秘密页面？
–卡尔加里
18年6月19日在15:58
切勿在robots.txt中放任何秘密！确保所有人都能找到您的机密页面的最佳方法是将其添加到robots.txt，因为发现机密所需要做的就是查看robots.txt。
– Moshe Katz
18 Jun 19'在20:35
@Kargari没有理由将实际机密页面的网址放入robots.txt。机械手文件完全能够禁止整个目录层次结构。如果您的秘密位于/nocrawl/page/sdghskdfjgneowsvnoiernow.htm中，则“ Disallow：/ nocrawl”指令将适用于它。
– jmbpiano
18年6月19日在22:21
@Kargari“ / nocrawl”是一个例子，不是处方。在尝试使用robots.txt文件之前，请先仔细阅读该文件的工作原理。
– jmbpiano
18年6月20日在14:03
“ Web浏览器具有内置的反网络钓鱼功能，可将访问的URL发送给欺诈检测服务” ...等等，这是什么？这样，欺诈检测功能可以查看每一个Google文档或您曾经“通过链接共享”的任何内容吗？
–user541686
18年6月20日在22:41
#4 楼
如果路径的秘密部分很长[...]，将很难猜测或强行使用它。
是的。攻击者必须猜测整个事物才能发现它。由于存在很多可能性，因此将花费大量的时间。
这种方法通常有什么问题？
这是因为URL不被认为是秘密的，因此会将它们存储在浏览器中，日志中以及任何中间代理中。这样，您的“秘密” URL可能会暴露出来。
使用GET处理活动内容时，CSRF变得微不足道。
不。在CSRF攻击中，攻击者伪造特定请求。在URL中使用机密时，攻击者甚至不知道伪造请求的正确URL。这意味着只要URL是秘密的，CSRF就不可能。
#5 楼
正如其他人所说，这不是一个好主意。这种用于退订或类似一次性目的的“秘密”链接通常是相对短暂的，一旦使用一次就没有用。当我阅读本文时，我的最初想法是问题是该URL不会长时间保密。我认为也许Chrome（或任何其他现代网络浏览器）会使用地址栏中的数据来初始化抓取。事实证明他们没有。但是，研究人员发现插件仍可能会触发爬网：
结果非常简单：Googlebot从未访问过测试中的任何页面。
事实证明，测试中的两个人实际上并未禁用其扩展，这导致了来自Open Site Explorer（有人安装并启用了Mozbar的人）和Yandex（由于其他人的访问）的访问，尽管我不清楚关于他们已安装和启用的扩展程序。）
这意味着一旦使用链接，浏览器扩展程序可能会损害该链接。这样就不需要强行使用任何东西了。
建立这些链接的目的是什么？ OP，您想达到什么目标？我敢肯定还有其他方法可以到达那里...
#6 楼
很难猜测/使用蛮力，但是其他获取路径的方法也可能是，例如，URL可能会被Google，Bing等服务编入索引。这会使您的“当用户在google中搜索您的页面时，将显示“秘密”网址。配置
robots.txt文件可以解决该问题，但请记住，索引器可能会忽略它应用程序中的链接可能会重定向到隐藏路径
此外，同一网络中的计算机当访问“秘密”页面或Web服务器的用户可以看到该URL时，每个中间代理和该用户的ISP（如果使用的话，也可以是VPN）都可以看到该URL。最后，URL可能会保留在浏览器的缓存和/或历史记录以及Web服务器和代理上的日志中
评论
切勿在robots.txt中放任何秘密！确保所有人都能找到您的机密页面的最佳方法是将其添加到robots.txt，因为发现机密所需要做的就是查看robots.txt。
– Moshe Katz
18年6月19日在20:36
@MosheKatz我没有说关于将秘密添加到robots.txt中的任何内容，但是进行了配置，以使您的页面不会被索引。诸如Disallow之类的东西：/
– E先生
18年6月19日在20:46
@MrE您可能知道，但是阅读您的答案的人可能不明白。
– Moshe Katz
18年6月19日在21:02
#7 楼
可以秘密执行GET请求吗？
是的，可以。与没有适当安全措施的任何类型的请求一样。
如果路径的秘密部分很长，我可以假定拥有这样的秘密页面或区域是安全的，
不，拥有这样的秘密页面或区域并不安全。是的，很难猜测或强行使用它。
这种方法通常存在什么问题？
与POST请求不同，可以在Web浏览器历史记录中轻松找到GET请求。
#8 楼
我认为最好采用自动或手动方式（以便您决定谁可以访问该页面）OTP一次性密码通过电子邮件发送。在手动方案中：
-您收到来自email@example.com的请求
-您授予对email@example.com的访问权限
-脚本使用OTP创建链接
-链接将被邮寄到email@example.com
-当用户email@example.com访问该页面时，将标记OPT，并且没有其他人可以重用该链接
当然，此系统需要一个数据库，存储授权的电子邮件，OPT和标志字段
评论
哦，您已经关闭了建议路径的目录列表和“智能错误”页面...请注意，一些成熟的Web服务将这种做法视为“足够好”，例如Google Docs（具有按链接共享功能）和Overleaf（协作的在线Latex编辑器）。
@FedericoPoloni：Google可能会跟踪批量请求并最终阻止它们。没有适当的设置，通过暴力破解（相对于URL的长度）更有可能成功。
密码重置链接中的@BgrWorker令牌应仅使用一次，然后丢弃。 OP要求的是可以重用的固定值，这不完全相同
@GoodDeeds链接共享是Google文档上允许的共享选项之一。您还可以决定共享到特定帐户，但这是另一回事。