ptf*_*ptf 16 security email search-engine
我在这里阅读了一些有关电子邮件客户端预取电子邮件中的 URL 的问题。对此的答案似乎是添加一个新的确认页面，用户必须在其中单击按钮来确认所需的操作。
但是，这个答案指出了以下内容：
截至 2017 年 2 月，Outlook ( https://outlook.live.com/ ) 会扫描到达收件箱的电子邮件，并将所有找到的 URL 发送到 Bing，以便由 Bing 爬网程序编制索引。
这实际上使得所有一次性使用的链接（例如登录/密码重置/等）变得毫无用处。
（我的服务的用户抱怨一次性登录链接对其中一些人不起作用，而且 BingPreview/1.0b 似乎在用户打开收件箱之前就点击了该 URL）
Drupal 似乎遇到了同样的问题： https ://www.drupal.org/node/2828034
我主要关心的是这个声明：
截至 2017 年 2 月，Outlook ( https://outlook.live.com/ ) 会扫描到达收件箱的电子邮件，并将所有找到的 URL 发送到 Bing，以便由 Bing 爬网程序编制索引。
如果是这种情况，则电子邮件中用于确认操作（例如确认登录、订阅或取消订阅）的任何 URL 最终都可以在搜索引擎中搜索到（如果这就是上面引用中的含义）indexed。在本例中，它是 Bing。即使是用户确认所需操作的专用确认页面也无法真正缓解这种情况。
如果我通过电子邮件向用户发送一个登录链接，其中 URL 中包含一次性令牌，则该 URL 最终将出现在 Bing 中。该令牌的生命周期很短，比如说 5 分钟，因此我怀疑是否有人会在用户点击该令牌或令牌过期之前在 Bing 上进行搜索并找到该 URL。
用户会收到一封电子邮件，其中包含确认订阅的链接。此链接的有效期可能为 24 小时。这可能（？）足够长，以至于其他人在搜索引擎上偶然发现该链接并意外（或故意）代表用户确认订阅。
场景 #2 并不罕见，据我所知，使用双重选择加入甚至是最佳实践。
取消订阅时事通讯底部的 URL。也许永远有效？您不希望在搜索引擎中公开搜索此内容。
假设所有一次性确认链接都位于用户确认所需操作的确认页面上。
电子邮件中的 URL 被搜索引擎（至少是 Bing）索引真的是问题所在吗？它们最终真的会被公开搜索吗？indexed如果不是，那么上面引用的内容是什么意思？
为了完整起见，我想补充一点，我认为我在使用网络时没有遇到太多问题，所以我的直觉是这种情况不太可能发生。
电子邮件中的 URL 被搜索引擎（至少是 Bing）索引真的是问题所在吗？
我不能肯定地说它们是否被索引，只有 Bing 可以回答这个问题，但它们肯定被访问过，至少是通过一个简单的 GET 请求。我刚刚测试了这一点，向自己发送了一个指向我网站上的页面的链接，该页面记录了针对该页面发出的请求，实际上我看到了一个 GET 来自207.46.13.181（反向 DNS 说msnbot-207-46-13-181.search.msn.com），这表明一个自动化程序search.msn.com正在抓取关联。这让我相信，是的，他们正在尝试以某种方式索引链接的内容，但这只是我的观点。
它们最终真的会被公开搜索吗？如果不是，上面引用中的“索引”是什么意思？
好吧，再说一次，除非你为 Bing 工作，否则很难说。无论如何，“索引”的含义正是您所认为的：解析页面内容以将其包含在搜索结果中。
这里真正的问题是：这是否在某种程度上代表了安全问题，或者是否会损害我网站的功能？
它肯定有潜力：如果您的确认/重置/订阅/任何过程仅依赖于具有适当 GET 参数的单个 GET 请求，那么您绝对应该重新访问该策略，因为它显然允许任何人执行该操作（甚至是恶意的）例如枚举 GET 参数的可能 ID）。
如果您尝试发送的链接包含敏感信息或可用于更改网站用户的重要数据，那么您至少应该将其放在登录页面后面，仅向感兴趣的用户提供访问权限。这样，任何想要访问它的人（包括搜索引擎）如果尚未登录，都将被重定向到登录页面。
如果您尝试发送的链接只是某种无害的确认链接（例如订阅/取消订阅时事通讯），那么至少使用网页内的表单通过 POST 请求进行实际确认（也可能使用CSRF 令牌），否则您将明确地得到误报。