我目前正在学习使用OpenID Connect Oauth2标准和Google身份验证。documentation表示使用防伪状态令牌来验证用户正在发出请求，而不是恶意攻击者。
我们将这个生成的状态令牌包含在与用户单击的“SigninwithGoogle”按钮相关联的URL中。URL看起来像这样：
https://accounts.google.com/o/oauth2/v2/auth?
response_type=code&
client_id=CLIENT_ID&
scope=openid%20email%20profile&
redirect_uri=appdomain.com&
state=**0Xgjymvk8tlPne45LPCnzfP3ofU5dm**&
nonce=0217322-3497425-1190558&
prompt=select_account用户接受后，Google重定向到REDIRECT_URI，并将stateparam和code param添加到URL中，如下所示：
https://appdomain.com/?state=0Xgjymvk8tlPne45LPCnzfP3ofU5dm&code=4%2F0AbUR2VP....这些状态参数都出现在前端。安全吗？是否可以通过检查它们在前端js代码中是否相同来验证它们？我不这么认为……
我们是否需要创建另一个链接附加到“使用Google登录”按钮，指向将生成状态令牌的后端服务，然后将用户重定向到第一个URL，让他接受使用Google登录？然后检查从前端的url参数中从Google接收到的状态令牌是否通过将其发送到将对用户进行身份验证的后端服务来检查在对用户进行身份验证之前是否相同？
你觉得这个怎么样？
谢谢你！
1条答案
按热度按时间8yparm6h1#
您链接的文档声明：
本文档介绍如何执行服务器流程以验证用户。隐式流要复杂得多，因为在客户端处理和使用令牌存在安全风险。如果您需要实施隐式流，我们强烈建议您使用Google Identity Services。
因此，您应该从后端生成状态，然后也检查后端的状态。同样，从您链接的文档中，它明确表示检查服务器上的状态***：
在服务器上，您必须确认从Google收到的状态与您在步骤1中创建的会话令牌相匹配。这种往返验证有助于确保发出请求的是用户，而不是恶意脚本。
如果你想了解更多……你应该看看OAuth 2.0规范：OAuth 2.0 -状态和CSRF
重要的是：
针对客户端的重定向URI的CSRF攻击允许攻击者注入其自己的授权代码或访问令牌，这可能导致客户端使用与攻击者的受保护资源而不是受害者的受保护资源相关联的访问令牌（例如，将受害者的银行账户信息保存到由攻击者控制的受保护资源）。
如果您有一个仅限客户端的应用程序（也称为SPA），使用授权代码流（使用PKCE！），攻击是恶意行为者让用户返回到具有其自己的授权代码的应用的重定向URI，该代码将获得用于访问恶意行为者的帐户的令牌。
通常情况下，应用程序只会获取此授权代码并将其发送到令牌端点，以将其交换为访问令牌。然后，用户认为她登录到她自己的帐户，但实际上登录到恶意行为者的帐户，并且在她更新她认为是她的帐户时无意中交出信用卡信息。
对于足够强的状态值，应用程序在获得授权代码时首先检查状态值。如果它不存在或者它不匹配它在授权请求早期发送的内容，它就知道这个授权代码没有绑定到它发起的授权请求。因此，它知道 * 不 * 发送令牌请求。
这里还有一个简短的解释，并链接到OWASP的更多资源：OWASP - CSRF此链接对于客户端应用程序中的各种类型的CSRF特别有用：OWASP - CSRF Cheat Sheet