【发布时间】:2021-06-05 11:29:46
【问题描述】:
据我了解,授权代码流相对于隐式流的优势在于,使用 ACF,访问令牌被发送到服务器端应用程序而不是浏览器应用程序。这使得访问令牌更难窃取,因为访问令牌永远不会到达浏览器(因此不易受到跨站点脚本攻击)。
我原以为 PKCE 会尝试解决这个问题。但事实并非如此。访问令牌仍会发送到浏览器。因此它仍然可以被盗。
我在这里缺少什么吗? 非常感谢。
【问题讨论】:
标签: oauth-2.0 pkce implicit-flow
据我了解,授权代码流相对于隐式流的优势在于,使用 ACF,访问令牌被发送到服务器端应用程序而不是浏览器应用程序。这使得访问令牌更难窃取,因为访问令牌永远不会到达浏览器(因此不易受到跨站点脚本攻击)。
我原以为 PKCE 会尝试解决这个问题。但事实并非如此。访问令牌仍会发送到浏览器。因此它仍然可以被盗。
我在这里缺少什么吗? 非常感谢。
【问题讨论】:
标签: oauth-2.0 pkce implicit-flow
授权码流 (PKCE) 被认为比先前的隐式流解决方案具有更高的安全性:
使用授权代码流可以更好地处理此问题,并减少漏洞利用范围:
PKCE 还提供保护,防止恶意方从浏览器响应中截取授权代码并能够将其交换为令牌。
两者都是客户端流程,它们存在的原因是在公共客户端中使用访问令牌。授权代码流程 (PKCE) 是所有这些的标准流程:
在 SPA 情况下,令牌不应该被轻易窃取,尤其是在建议仅存储在内存中的情况下。不过在浏览器中使用token的时候有更多的顾虑,因为这是一个危险的地方,你需要关注SPA Best Practices。
在浏览器的情况下,当然还有其他选项,例如通过 Web 后端或反向代理路由请求以将令牌排除在浏览器之外,以及在使用令牌之外处理身份验证 cookie。
【讨论】:
我认为你是对的。令牌不在 http-only cookie 中,因此可以被恶意脚本访问(通过 XSS 攻击注入)。攻击脚本可以从本地存储(或放置它们的任何位置)读取所有令牌(在成功且正常的身份验证流程之后)并使用它们。
我认为 CORS 保护应该防止恶意脚本直接将令牌发送给攻击者,这将是毁灭性的失败,因为这可能包括长期存在的刷新令牌。因此,我怀疑在使用这些基于本地客户端的流程(本地客户端是指浏览器、移动应用程序或本地 PC 应用程序)时,正确配置 CORS 非常关键。
简而言之,这些本地客户端流可以变得安全,但如果存在 XSS 攻击或错误配置的 CORS,那么这些攻击可能会变得非常危险 - 因为刷新令牌可能会被发送给攻击者在他们自己的好时机随意使用,这与攻击一样糟糕。
【讨论】: