带有令牌参数的https URL:安全吗?

110
在我们的网站上,我们根据用户通过表单提供的个人信息提供模拟。我们希望允许他们稍后获取他们的模拟结果,但不强制要求他们创建登录/密码帐户。
我们考虑向他们发送一封电子邮件,其中包含一个链接,从中他们可以获取他们的结果。但是,自然地,我们必须保护此URL,因为涉及私人数据。
因此,我们打算在URL中传递令牌(例如40个字符的字母和数字组合或MD5哈希),并使用SSL。
最后,他们将收到像这样的电子邮件:
“嗨,
获取您的结果https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn 你认为这安全吗?您对令牌生成有何建议?如何通过https请求传递URL参数?

1
http://www.securityweek.com/hackers-can-intercept-https-urls-proxy-attacks - Tom
9个回答

125

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

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

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

最后,也是使此非常不安全的原因是,URL在所有请求的Referer标头中发送给任何资源,甚至是第三方资源。 所以,如果您例如使用Google Analytics,则会将URL令牌发送给Google。

我认为这是一个坏主意。


1
我之前没有考虑过HTTP-referer问题,但是URL链接会重定向到结果页面,这不是一个适当的页面(没有Google Analytics或其他第三方脚本)。 - Flackou
7
大多数浏览器在从HTTPS跳转到HTTP时会删除引用来源吗? - Kevin Mark
3
这类似于用户激活(或密码重置)链接,对吗?那么该如何处理这种情况呢?很多网站会把重置链接发送到用户的电子邮件中,因为需要可点击的链接,所以POST不是一个选项。谢谢。 - pinkpanther
4
那么,解决方案是什么? - R T
1
如果URL中的令牌与用于API请求的令牌不同,并且仅持续一小时,那么会有什么危害呢? - user1709076
如果该令牌被泄露,攻击者将有一小时的时间来冒充您的用户。危害取决于您的应用程序。在我看来,通过电子邮件发送是可以接受的,只要令牌具有短暂的时间范围并且只能使用一次。 - JoshBerke

16
我会为此使用 cookie。工作流程应该是这样的:
  1. 用户首次访问您的网站。
  2. 站点设置一个cookie。
  3. 用户输入数据。使用存储在cookie中的某些密钥将数据存储在数据库中。
  4. 当用户离开时,您向他们发送带有https:链接的电子邮件。
  5. 当用户回来时,站点发现cookie并可以向用户呈现旧数据。

现在,用户想要在不同的浏览器或机器上使用。在这种情况下,提供一个“转移”按钮。当用户点击此按钮时,她将获得一个“令牌”。她可以在另一台计算机上使用此令牌来重置cookie。这样,用户可以决定如何安全地传输令牌。


如果新电脑上没有cookie,服务器如何知道他们是谁?在用户不知道自己是谁以及结果属于谁的情况下给予令牌是没有意义的。我有什么遗漏吗? - scrollout
我想象如果用户清除了他们的Cookie,他们的网站数据将无法访问或被删除。 - Bill Willian

4

SSL可以保护数据在传输过程中的内容,但对于URL我不确定。

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

如果用户的电子邮件被攻击者入侵并首先获取了该链接,那么你就会受到损失。但用户也有更大的问题。


13
在传输URL之前,SSL连接会受到保护。 - David

1

电子邮件本质上是不安全的。如果任何人都可以点击该链接并访问数据,那么您实际上并没有保护它。


确切地说,许多网站并不关心这一点,会通过电子邮件发送登录名和密码。但这并不是模仿他们的理由... - Flackou
我同意没有模仿他们的理由,但他们通常会要求你在第一次登录后更改密码。 - Jason Punyon

1

当通过SSL传递令牌时,令牌是安全的。 你将面临的问题是,人们(那些不打算使用它的人)可以通过查看URL来获得它。

如果涉及私人信息,例如社会安全号码,我认为我不会通过电子邮件发送URL。 我宁愿让他们为该网站创建用户名和密码。 对于你和他们而言,这种信息的利害关系太大了,很容易破坏电子邮件。 如果某人的帐户受到攻击,就会质疑到底是谁的责任。 从严格的CYA角度来看,越安全越好。


1
你是对的:例如,URL将保留在浏览器历史记录中。 - Flackou

0

按照现在的方式,这是一个不好的想法。您将以易用性为代价牺牲安全性。正如之前所说,SSL仅保护服务器和客户端浏览器之间的信息传输,并且仅防止中间人攻击。电子邮件非常危险和不安全。

最好的方法是使用用户名和密码身份验证来访问信息。

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

关键短语可以存储在Cookie中以便于使用,但请记住,Cookie也可能会被盗取 =(。

最好让客户端输入他提供的关键短语,该关键短语与他的数据一起存储在数据库中。

或者,如果用户使用的机器与$_SERVER['HTTP_USER_AGENT']参数不同或者简单地错过了Cookie,则可以使用密钥。因此,Cookie可以被传输或设置。

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


0

你知道如果黑客获取了你的数据库,很多个人信息将会被自由地泄露吗?

在那之后,我会说这不是一个坏主意。我不会使用 MD5 或 SHA1,因为它们对于哈希不是非常安全。它们可以相当容易地“解密”(我知道这不是加密)。

否则,我可能会使用第二个信息来作为密码,该信息不会通过电子邮件发送。原因很简单,如果有人访问了用户的电子邮件(如果您没有终结会话,在 Hotmail 上相当容易),他将可以访问用户发送的任何信息。

请注意,HTTPS 将保护和加密从您的站点发送到最终用户的数据。仅此而已,把它视为安全通道。没有更多也没有更少。


在任何意义上,盐值 SHA1 哈希如何被解密? - Eli
"你知道如果黑客获取了你的数据库,很多个人信息都会被自由地泄露吗?" 是的,但难道不是所有网站都面临这个问题吗? - Flackou
@Flackou 如果你成功访问了PayPal的数据库,你不会找到明文保存的信用卡信息,因为所有信息都是加密的。@Eli:http://www.theregister.co.uk/2005/02/17/sha1_hashing_broken/ - Erick

0

我真的不认为这对于存在严重隐私问题的情况足够安全。你通过电子邮件发送URL(可能是明文)是最薄弱的环节。此外,令牌面临暴力攻击的风险,缺乏真正身份验证机制的结构,比良好构建的用户名和密码设置更容易受到攻击。

顺便说一下,在https请求中,参数没有任何问题。


你对暴力攻击的风险说得没错。我不知道我们如何防止机器人进行这种攻击。禁止“坚持”的IP地址并不能提供足够的保护。你有什么想法吗? - Flackou
实际上,针对我们所讨论的密钥空间,将 if(this_ip_number_has_requested_an_invalid_token_today()) sleep(5); 放在您的 load_simulation 脚本中将是完全足够的保护措施。(速率限制是良好认证机制的一个特点。) - chaos
谢谢您的回答。但是我认为同一个机器人可以轻松地使用不同的IP地址,这使得IP速率限制不足。我错了吗? - Flackou
他们只能获得每个IP地址一个未延迟的尝试。IP地址空间并不容易获取,因此这并没有什么帮助。 - chaos

-1
据我理解你的想法,理论上有人可以输入一个随机的40个字符的字符串或MD5哈希值,然后获取到别人的详细信息。虽然这种情况可能性非常小,但只需要发生一次就足够了。
更好的解决方案可能是向用户发送一个令牌,然后要求他们输入一些详细信息,例如他们的姓名、邮政编码、社会安全号码或这些信息的组合。

6
社会安全号码?你是认真的吗?无论如何,我建议你算一下有多少个40个字符的随机字符串。它不仅仅是“非常不可能”。 - Eli
1
各位,62的40次方远远超过宇宙中原子的数量。它是真正无法猜测的。 - Eli
2
我很惊讶有多少人无法理解这些数字的规模。如果你猜测每秒钟一百万个代币,那么太阳在你获得命中之前烧尽的可能性更大。 - Eli
你不必遍历每一个可能性才能找到匹配,如果有人的URL恰好在前一百万个可能性中,会发生什么? - Richard Slater
5
Richard,听起来你在指出通常被称为生日悖论的内容...重要的不仅是可能的组合数,而是有多少组合被使用。在这种情况下,您需要使用大约 62 ^ 40 中的 2 ^ 119 个组合才能使概率变得显著。 - erickson
显示剩余4条评论

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接