带有令牌参数的 https URL：它有多安全？

Posted 2023-03-10

【中文标题】带有令牌参数的 https URL：它有多安全？

【英文标题】：https URL with token parameter : how secure is it?

【发布时间】：2010-10-13 04:51:58

【问题描述】：

在我们的网站上，我们根据用户的私人信息（通过表格提供）向用户提供模拟。我们希望允许他们稍后返回他们的模拟结果，但不会强迫他们创建登录/密码帐户。

我们考虑向他们发送一封带有链接的电子邮件，他们可以从中获取结果。但是，很自然，我们必须保护这个 URL，因为私人数据受到威胁。

所以我们打算在 URL 中传递一个令牌（如 40 个字符的字母和数字组合，或 MD5 哈希）并使用 SSL。

最后，他们会收到这样的电子邮件：

嗨， 取回您的结果 https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn

你怎么看？是否足够安全？对于令牌生成，您有什么建议？在 https 请求中传递 URL 参数呢？

【问题讨论】：

securityweek.com/hackers-can-intercept-https-urls-proxy-attacks

【参考方案1】：

SSL 将保护传输中的查询参数；但是，电子邮件本身并不安全，电子邮件在到达目的地之前可能会通过任意数量的服务器反弹。

另外，根据您的 Web 服务器，完整的 URL 可能会记录在其日志文件中。根据数据的敏感程度，您可能不希望您的 IT 人员访问所有令牌。

此外，带有查询字符串的 URL 将保存在您的用户历史记录中，允许同一台计算机上的其他用户访问该 URL。

最后，这个非常不安全的地方在于，URL 是在对任何资源的所有请求的Referer 标头中发送的，甚至是第三方资源。因此，例如，如果您使用 Google Analytics（分析），您将向 Google 发送 URL 令牌并将其全部发送给他们。

在我看来这是个坏主意。

【讨论】：

我没有考虑过 HTTP-referer 问题，但是 url 链接会重定向到结果页面，它不是一个正确的页面（没有谷歌分析或其他第三方脚本）。

大多数浏览器在从 HTTPS 转到 HTTP 时不会删除引荐来源网址吗？

这类似于用户激活（或密码重置）链接，对吧？那这个案子应该怎么处理呢？许多网站将重置网址发送到电子邮件，POST 不是一个选项，因为它应该是可点击的。谢谢。

那么解决办法是什么？

如果url中的token和api请求使用的token不一样，只持续一小时，会有什么危害呢？

【参考方案2】：

我会为此使用 cookie。工作流程应该是这样的：

用户第一次访问您的网站。 网站设置 cookie 用户输入数据。数据使用存储在 cookie 中的某个密钥存储在数据库中。 当用户离开时，您向他们发送一封带有 https: 链接的电子邮件 当用户回来时，网站会发现 cookie 并可以向用户展示旧数据。

现在，用户想要在不同的机器上使用不同的浏览器。在这种情况下，提供一个“转移”按钮。当用户点击这个按钮时，她会得到一个“令牌”。她可以在另一台计算机上使用此令牌来重置 cookie。这样，用户就可以决定她希望转移令牌的安全程度。

【参考方案3】：

SSL 保护传输中数据的内容，但我不确定 URL。

无论如何，减轻攻击者重复使用该 URL 令牌的一种方法是确保每个令牌只能使用一次。您甚至可以设置一个 cookie，以便合法用户可以继续使用该链接，但在第一次访问后，它只对拥有 cookie 的人有效。

如果用户的电子邮件被泄露，并且攻击者首先获得了链接，那么你就完蛋了。但用户也有更大的问题。

【讨论】：

在传输 URL 之前 SSL 连接是安全的。

【参考方案4】：

电子邮件本质上是不安全的。如果任何人都可以单击该链接并获取数据，那么您并没有真正保护它。

【讨论】：

没错，但许多网站并不关心这一点，而是通过邮件发送登录名/密码。但这不是模仿他们的理由......

我同意没有理由模仿他们，但他们通常会在您第一次登录后告诉您更改密码。

【参考方案5】：

当通过 SSL 传递时，令牌是安全的。您将遇到的问题是，人们（那些不适合使用它的人）可以通过查看 URL 来使用它。

如果是像 SSN 这样的私人信息，我认为我不会通过电子邮件发送 URL。我宁愿让他们为该站点创建用户名和密码。对于您和他们来说，使用此类信息危及您的利益的电子邮件太容易泄露。如果某人的帐户被盗用，就会有人质疑这到底是谁的错。从严格的 CYA 角度来看，您越安全越好。

【讨论】：

你是对的：例如，该 URL 将保留在浏览器历史记录中

【参考方案6】：

您知道，如果任何黑客访问您的数据库，可以免费提供大量个人信息？

在那之后，我会说这主意不错。我不会使用 MD5 或 SHA1，因为它们对于散列不是很安全。它们可以很容易地被“解密”（我知道这不是加密）。

否则，我可能会使用不会通过电子邮件发送的第二个信息，例如密码。原因很简单，如果有人可以访问用户的电子邮件（如果您不终止会话，使用 hotmail 很容易）他将可以访问用户发送的任何信息。

请注意，HTTPS 将保护和加密从您的站点发送给最终用户的数据。没有别的，把它当作一个安全的隧道。不多不少。

【讨论】：

加盐 SHA1 哈希究竟是如何解密的？

"您知道如果任何黑客访问您的数据库，很多个人信息都可以免费提供吗？"是的，但不是所有网站都有问题吗？？

@Flackou 是的，但是如果您可以访问 paypal 的数据库，您将找不到清晰保存的信用卡信息，所有内容都是加密的。 @Eli：theregister.co.uk/2005/02/17/sha1_hashing_broken

【参考方案7】：

对于存在严重隐私问题的情况，我真的认为这不够安全。您在（可能是明文）电子邮件中发送 URL 的事实是迄今为止最薄弱的环节。之后是对令牌进行暴力攻击的风险，令牌（缺乏真正的身份验证机制的结构）可能比结构良好的用户名和密码设置更容易受到攻击。

顺便说一句，https请求中的参数完全没有问题。

【讨论】：

暴力攻击的风险是正确的。我不明白我们如何能防止机器人受到这种类型的攻击。禁止“坚持”IP 将不足以提供保护。你对这个主题有什么想法吗？

实际上，对于我们正在谈论的那种密钥空间，放置一个 if(this_ip_number_has_requested_an_invalid_token_today()) sleep(5);在您的 load_simulation 脚本中将是完全足够的保护。 （速率限制是良好身份验证机制的特征之一。）

感谢您的回答。但我认为同一个机器人可以轻松获取不同的 IP，这使得 IP 速率限制不够。我错了吗？

获得它们的只是每个 IP 一次无延迟的尝试。 IP 地址空间不那么容易获得，这很有帮助。

【参考方案8】：

事实上，这将是一个坏主意。您将轻松使用安全性。如前所述，SSL 只会保护服务器和客户端浏览器之间的信息传输，只会防止中间人攻击。电子邮件非常危险且不安全。

最好是通过用户名和密码验证来访问信息。

我或多或少喜欢 cookie 的想法。您还应该加密 cookie 信息。 您还应该使用盐和关键短语以及 $_SERVER['HTTP_USER_AGENT'] 生成令牌以限制攻击的可能性。在 cookie 中存储尽可能多的关于客户端的非敏感信息以供验证使用。

可以将关键短语存储在 cookie 中以便于使用，但请记住，cookie 也可能被盗 =(.

最好让客户键入他提供的关键字，该关键字也与他的数据一起存储在数据库中。

或者，如果该人使用不同的 $_SERVER['HTTP_USER_AGENT'] 参数或只是错过了 cookie 的机器，则可以使用该密钥。所以cookie可以被传输或设置。

还要确保数据库中的敏感数据已加密。你永远不知道;)

【参考方案9】：

根据我对您的想法的理解，理论上有人可以输入随机的 40 个字符串或 MD5 哈希值并获取其他人的详细信息。虽然这不太可能发生，但它只需要发生一次。

更好的解决方案可能是向用户发送令牌，然后要求他们输入一些详细信息，例如他们的姓名、邮政编码、ssn 或这些的组合。

【讨论】：

社保号？你是认真的吗？无论如何，我建议你计算一下有多少 40 个字符的随机字符串。这不仅仅是“极不可能”

你是对的，我们可能应该在 url 中添加另一个参数，比如电子邮件（即使 a..z + A..Z + 0..9 = 62 个字符，并且 62^ 40 是一个相当大的数字）。

伙计们，62^40 比宇宙中原子的数量要多得多。这简直无法猜测。

我很惊讶有多少人无法掌握这些数字的规模。如果你在一秒钟内猜测一百万个代币，那么太阳在你被击中之前就很可能会燃烧殆尽

Richard，听起来你在指出通常被称为生日悖论的东西......重要的不仅仅是可能组合的数量，而是使用了多少组合。好吧，在这种情况下，您需要使用 62^40 个组合中的大约 2^119 个，然后机会变得很大。