英文:
When using Authorization code grant with the Proof Key of Code Exchange, can't the final access token response be captured by the malicious app?
问题
根据我对在本机应用程序中使用授权码授权与代码交换的证明密钥的理解，认证服务器在验证原始代码验证器并将其与最初发送的代码挑战进行比较后，向应用程序发送包含访问令牌的响应。
但是，响应中的访问令牌是否能够被恶意应用程序捕获并用于访问受限数据呢？
对于单页Web应用程序也有同样的问题。如果它们实施了PKCE，浏览器扩展是否能够捕获包含访问令牌的最终响应？
英文:
From what I understood about using Authorization code grant with the Proof Key of Code Exchange in native applications, the auth server sends a response with the access token to the application after validating the original code verifier and comparing it with the code challenge sent initially.
But can't the response with access token be captured by a malicious app and used to access restricted data?
Same question for Single Page Web Apps. If they implement PKCE, can't a browser extension capture the final response with access token?
答案1
得分: 2
特定的漏洞与应用程序能够拦截任何HTTP请求无关。它与授权端点重定向回应用程序有关。
在用户被发送到 redirect_uri 位置之后，需要将其交回给最初从浏览器请求的应用程序。
这种交接并不是非常安全的，其他应用程序有可能拦截它。
不过，如果一个应用程序能够拦截任何HTTP请求/响应，那么PKCE也不会对你有太大帮助。
英文:
The specific vulnerability is not related to apps being able to intercept any HTTP requests. It has to do with the redirect from the authorization endpoint back to the app.
After a user is sent to the redirect_uri location, a hand-off needs to happen back to the app that originally requested it from a browser.
This hand-off is not terribly secure, other apps can potentially intercept this.
You are right though that if an app is able to intercept any HTTP request/response then PKCE won't help you much.
答案2
得分: 1
PKCE只证明完成登录的一方是发起登录的一方。根据OAuth 2.1的规定，所有客户端都应该使用它，但它并不能解决所有问题。最佳实践取决于应用程序类型：
移动应用
你可以使用基于声明的HTTPS方案重定向URI，它限制了令牌的交付，只允许特定应用程序访问重定向URI。
桌面应用
在这里，最好的做法是基于私有URI方案的重定向URI，可能还结合组织策略，只接受来自白名单来源的应用程序，例如具有经过批准的根CA链的受信任代码签名。
单页应用（SPA）
考虑到已知威胁，前端用于后端的是最佳选择，它只向浏览器返回最新的安全cookie。然后，扩展可能能够执行会话劫持，但不能窃取用于更有针对性的攻击的后端凭据。
英文:
PKCE only proves that the party conpleting login is the party that started the login. It should be used by all clients according to OAuth 2.1, but does not solve all problems. The best practices vary depending on the application type:
MOBILE
You can use Claimed HTTPS Scheme Based Redirect URIs which restricts token delivery to a redirect URI that only a particular app can access.
DESKTOP
The best you can do here is private URI scheme based redirect URIs, perhaps combined with an organization policy to only accept apps from whitelisted sources, eg with trusted code signing that chains up to an approved root CA.
SPAs
A Backend for Frontend is considered the option with best understood threats, by only returning the latest secure cookies to the browser. An extension might then be able to perform session hijacking, but could not exfiltrate a backend credential for more concerted attacks.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论