我是OAuth世界的新手,我试图理解使用PKCE比传统授权代码授予的好处。(我的许多假设可能是错误的,所以我要感谢你的修正。)
我是一个移动应用程序开发人员,根据OAuth文档,客户机密不能硬编码在公共客户端的应用程序代码中。避免对客户端秘密进行硬编码的原因是,黑客可以解压缩我的应用程序并获取我的客户端秘密。
拥有我的客户机密和我的redirect_url的黑客可以开发一个假的应用程序。如果最终用户(User1)下载真正的应用程序和黑客的应用程序(两者都下载),伪造的应用程序可以监听真正的应用程序回调,并从其中获取授权代码。使用授权代码(来自回调)和客户端秘密(通过反编译我的应用程序窃取),黑客可以获得授权令牌和刷新令牌,并能够获取用户1的数据。
如果其他用户下载真实的和假的应用程序,他们的数据也将处于危险之中。我说的对吗?黑客是两者都需要,还是只能使用授权代码进行攻击?映像的第五步是否需要客户端的机密和授权代码?
这种攻击称为拦截攻击。

为了解决在公共客户端应用程序中硬编码客户端秘密的问题,使黑客无法获取客户端秘密并盗取令牌,提出了PKCE。使用PKCE,客户端应用程序代码不需要硬编码客户端秘密,因为PKCE不需要这些信息来获取最终用户的令牌。
PKCE流创建一个随机字符串,将其转换为沙-256哈希值和Base64。在映像的第二点中,编码的字符串使用客户端id发送到身份验证服务器。然后在回调中发送授权代码,如果有恶意应用程序截取代码,它将无法获得令牌,因为图像的第五点需要合法应用程序创建的原始随机字符串。
这很好,但是如果客户端秘密不再需要获得令牌来访问User1数据,那么我如何避免黑客开发一个使用PKCE流和我的客户端id一起使用PKCE流的假应用程序,以及获取那些认为该应用程序是合法应用的用户的令牌呢?
由于图像的第五步不再需要任何客户端秘密来获取令牌,任何人都可以使用我的公共客户端id开发假应用程序,如果有用户下载假应用程序并执行OAuth流,黑客可以获取其令牌并访问用户数据!
我说的对吗?
发布于 2022-01-29 21:21:22
如果不再需要客户端秘密来获取令牌来访问User1数据,那么如何避免黑客开发一个使用PKCE流和我的客户端id一起使用PKCE流的假应用程序,并获得那些认为该应用程序是合法应用的用户的令牌?
OAuth 2.0或PKCE并不能抵御“假应用程序”。
PKCE确实可以防止在设备上安装恶意应用程序来窃取另一个应用程序的令牌。例如,想想一个银行应用程序,如果设备上的另一个应用程序能够获得银行应用程序正在使用的令牌,那就不好了。这是在您的图片中说明的情况,并且PKCE减轻了这种情况。
由于图像的第五步不再需要客户端秘密来获取令牌,任何人都可以使用我的公共客户端id开发假应用程序。
移动应用程序不能保护客户端机密,类似于JavaScript单页应用程序。因此,根据OAuth 2.0,这些客户端是公共客户端而不是机密客户端。只有机密客户端才能以安全的方式保护客户端秘密,只有那些应该使用客户端机密的客户端才能保护客户端机密。PKCE是一种很好的公共客户端技术,但也可以用于机密客户端。
如果有任何用户下载这个假应用程序并执行oauth流,黑客可以获得它的令牌并访问用户的数据!
联系苹果商店或谷歌游戏商店的“假应用程序”,或使用例如反恶意软件应用程序。这就是对抗“假应用程序”的缓解措施。PKCE只在同一设备上的另一个应用程序试图窃取另一个应用程序(例如银行应用程序)的令牌时才能缓解这种情况。
https://stackoverflow.com/questions/70767605
复制相似问题