取消
显示结果 
搜索替代 
您的意思是: 
cancel
公告

December 2020

December 2020

【原创】你需要知道的用户会话安全都在这里!(2)

26
查看次数
0
有帮助
0
评论
  1. 将短—中期有效的令牌,用于获取新的访问令牌
    • 即使先前的令牌尚未过期,前端也可以使用新的访问令牌。
    • 在用户主动注销会话的时候,访问令牌将在后端被吊销,并从前端被清除。
    • 如果访问令牌仅短期有效,那么用户就需要尽快注销会话。

攻击分析

关键的认证令牌会永久性地暴露在前端、传输通道和后端,三个攻击面上。

认证令牌被盗的影响:

攻击者必须不断地更新其令牌,以维持其未经授权的访问状态。

盗用检测:

要保持登录状态,攻击者和受害者都需要在当前(被盗)令牌过期之前,向服务器请求新的访问令牌。如果同一令牌两次被用于该请求,那么系统会根据前端的实现方式,推断出发生了盗用行为。可见,短—中期有效的令牌虽然可以更快地被检测出是否存在盗用,但是同样由于寿命短暂,就算没有被盗用,用户的体验也并不佳。当然,一旦盗用行为被检测到,与该会话关联的访问令牌将会被立即吊销。不过,如果访问令牌是JWT,那么阻止此类攻击可能会比较复杂。

  1. 短—中期访问令牌,其使用期限会延长
  • 在用户主动注销会话的时候,访问令牌将被吊销,并在前端被清除。

攻击分析

关键的认证令牌会永久性地暴露在前端、传输通道和后端,三个攻击面上。

认证令牌被盗的影响:

只要受害者的会话处于有效状态,攻击者就可以维持未经授权的访问。

盗用检测:

只能通过使用主动的启发式算法、或被动地依靠用户通知再实施检测。一旦盗用行为被检测到,与该会话关联的访问令牌将会被立即吊销。不过,如果访问令牌是JWT,那么阻止此类攻击可能会比较复杂。

4.短期访问令牌

  • 在用户主动注销会话的时候,访问令牌将被吊销,并在前端被清除。

攻击分析

在这种情况下,虽然没有关键的认证令牌,但是由于在传输过程中会公开用户的凭据,因此同样容易受到中间人的攻击。

认证令牌被盗的影响:

如果令牌被盗,攻击者将只能在短时间内实施未经授权的访问。

盗用检测:

只能通过使用主动的启发式算法、或被动地依靠用户通知再实施检测。在检测到攻击时,由于访问令牌寿命非常短,因此我们无需吊销它们。不过,如果确实需要,我们可以通过从数据库中删除Opaque访问令牌的方式,来吊销它们。

  1. 短期访问令牌和长期刷新令牌
  • 在用户主动注销会话的时候,访问令牌和刷新令牌将被吊销,并在前端被清除。

攻击分析

关键的认证令牌(和刷新令牌)会永久性地暴露在前端和后端两个攻击面上,当然也偶尔会在传输过程中被暴露。

认证令牌被盗的影响:

访问令牌被盗:直到该令牌到期之前,攻击者会在短时间内拥有未经授权的访问权限。

刷新令牌被盗:攻击者可以通过盗取刷新令牌,来获取新的访问令牌,并在较长一段时间内,以未经授权的方式访问受害者的帐户。

盗用检测:

访问令牌被盗:只能通过使用主动的启发式算法、或被动地依靠用户通知再实施检测。

刷新令牌被盗:只有在极少的情况下,我们能够检测到此类盗用行为,并将损失降至最低。例如:通过某种实现方式,让先前的访问令牌在生成新的令牌之后,立即被吊销。据此,系统可以在攻击者和受害者同时在线的情况下,识别出盗用的行为。也就是说,如果攻击者使用了刷新令牌,那么受害者的访问令牌将会被吊销,也就导致了受害者需要去请求新的访问令牌。而这将迫使攻击者发出另一个请求,依此类推。因此,如果后端能够检测到在较短间隔内,系统产生了大量对于新访问令牌的请求,则可以推断出盗用的状况。

在检测到攻击时,由于访问令牌的寿命非常短,因此我们无需吊销它们。不过,如果确实需要,我们可以通过从数据库中删除Opaque访问令牌,来吊销它们。

下面,我们针对不同的会话攻击类型,讨论各种相应的应对方法。

应对攻击的最佳实践

中间人袭击

当会话仅使用HTTP,或错误地实现了HTTPS时,如果应用程序并未启用HTTPS、以及安全的cookie,那么攻击者就可以通过与受害者同处一个网络,来监视网络中的各种数据包,并在传输过程中以纯文本格式,去查看到认证令牌。此外,即使某些应用程序带有SSL证书,而错误的实现方式也可能导致中间人攻击得逞。

正如前面提到的,预防此类攻击的最简单方法是:在整个应用程序中正确地使用HTTPS和安全的cookie。此外,我们还可以通过在每台设备上使用公有、私有密钥来增强额外的预防力度。也就是说,在用户登录之前,前端和后端将在初始化时交换此类公钥。另外,为了后续通信的安全起见,我们也可以使用公钥对令牌数据进行加密。

OAuth令牌盗用

如果某个应用程序是通过OAuth的方式,向其他应用程序提供访问和刷新令牌。那么当其他应用程序的所在服务器受到威胁时,该应用本身的认证令牌也具有被盗的风险。前文提到的Docker Hub典型案例,就是属于此类型。

那么预防此类攻击的解决方法是:采取适当的措施,及时检测处被盗的刷新令牌,并仅使用短期有效的访问令牌类型。

XSS攻击

XSS中,攻击者可以恶意地将Javascript注入到受害者的浏览器里,并运行在各种应用程序中。此类注入代码会读取认证令牌,并将其回传给攻击者。如果您想了解更多有关XSS攻击的信息,请参见--https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

通过使用HttpOnly或各种Secure cookie来存储认证令牌,我们可以很容易地防御此类攻击的发生。不过,值得注意的是:请勿使用localStorage来存储认证令牌,因为它们会被Javascript所访问到。

CSRF

此类攻击的目的并非窃取认证令牌,而是让攻击者可以跟踪(piggyback)现有的活动会话。

为了防止CSRF攻击,我们通常需要使用anti-CSRF令牌或SameSite cookie。当然,您也可以使用其他的方法,来与整个认证过程无缝地结合到一起,以解决此类问题。

数据库/文件系统访问

如果攻击者获得了有效的认证令牌、或JWT/SSL私钥(此类密钥的盗用往往比密码被盗更为糟糕),就能够设法通过数据库的注入攻击,来访问到服务器,乃至数据库和文件系统理的信息。据此,他们将能够轻松地劫持会话,进而产生严重的安全后果。值得注意的是,攻击者很可能是贵组织内部的雇员,所以我们在对数据库/服务器实施访问控制时,需要注意如下两个方面:

  • 仅在数据库中存储刷新和访问令牌的哈希值,以防止攻击者劫持到任何实时的会话。
  • 由于JWT需要将私钥存储在服务器上,因此一旦攻击者获得了私钥,他们将能够劫持当前、以及将来的会话。为了限制攻击面,我们需要修改用于签发JWT的私钥,以便让所有当前的JWT都立即失效。而由于刷新令牌将被用于生成一个带有新的私钥签名的JWT,因此该更改私钥的方法并不会影响到用户的体验。

会话固定

此类攻击“主打”Web应用程序里的匿名会话,而应对的最佳方法是:让用户每次登录时,都生成一组新的认证令牌,并使旧的令牌(如果有的话)及时失效。注意,这是基于设备而不是基于用户实现的。

蛮力攻击

那些具有足够资源的攻击者,经常会不断地去“猜测”认证令牌,直到其中的一种尝试成功通过为止。据此,他们将获得被盗令牌所授予的所有访问权限。而抵御此类攻击的最佳方法是:使用带有高熵(high entropy)且位数较长的认证令牌。

总结

通过上述分析,我们了解到了会话管理的基本概念、常见的会话安全缺陷、各种攻击类型、以及应对措施的最佳实践。希望本文能够给您在系统架构设计的实践和安全管理中提供帮助。

【原标题】All You Need to Know About User Session Security (作者: Supertokens   )

 

Content for Community-Ad


不能显示该小部件。