CSRF的目的是通过单击攻击者发送的链接，欺骗用户在网站中执行操作（通常是用户在正常情况下不会执行的破坏性写操作）。此类活动的一个示例是删除网站中用户自己的帐户。假设用户已登录该网站，则来自该用户浏览器的请求将受到该网站服务器的信任，该服务器无法（在没有CSRF令牌的情况下）查明该用户实际上是由该用户发出的。

对于Google OAuth2（授权码授予类型），请注意，对Google auth服务器的初始请求包含用户在成功进行身份验证后实际要访问的URL。攻击者可以出于恶意目的精心构造该URL，并让用户使用它。

状态令牌检查使服务器可以确保请求确实来自其自己的网站，而不是来自其他任何地方。如果攻击者使用一些随机状态令牌创建了url，则服务器将无法识别该URL并拒绝该请求。

如果您有这样的疑问，那么您必须参考的最佳资源就是规范。对于OAuth 2.0，这是RFC6749。规范中有专门的部分讨论Cross-Site Request Forgery

  

跨站点请求伪造（CSRF）是攻击者利用的一种利用      导致受害最终用户的用户代理遵循恶意URI      （例如，作为误导性链接，图片或      重定向）到信任服务器（通常通过      存在有效的会话Cookie）。

从规范的角度来看，您必须在应用程序中实现 state 处理机制

  

客户端必须为其重定向URI实现CSRF保护。      这通常是通过要求将任何请求发送到      重定向URI端点，以包括将请求绑定到的值      用户代理的身份验证状态（例如会话的哈希）      用于验证用户代理的Cookie）。客户应      利用“状态”请求参数将该值传递给      授权请求时使用授权服务器。

有关详细说明，直接来自标本

  

针对客户端重定向URI的CSRF攻击允许攻击者      注入自己的授权码或访问令牌，      导致客户端使用与      攻击者的受保护资源，而不是受害者的受保护资源

注入来自攻击者的授权代码，然后操纵您的应用程序以使其表现出攻击者想要的方式。

在OAuth2中使用授权代码流时，用户浏览到客户端应用程序，然后将浏览器重定向到授权服务器以进行登录并获得访问令牌。

302 https://auth.server/authorize?response_type=code&client_id=....

在授权服务器上登录后，它将使用发出的代码将您重定向回注册的重定向URI。然后，客户端应用程序将代码替换为访问令牌，并有选择地转到状态参数中编码的URL。

现在，攻击者可能会诱骗您单击链接（从电子邮件或类似内容），例如：

<a href="https://auth.server/authorize?response_type=code&client_id=...."

这将对授权服务器执行相同的请求。登录后，授权服务器将您重定向回客户端应用程序，客户端应用程序将无法知道传入的带有授权码的GET请求是由发起的302重定向还是单击该请求引起的恶意电子邮件中的超链接。

客户端应用程序可以通过在授权请求的状态参数中添加一些熵来防止这种情况。由于状态参数将作为查询参数包含在返回客户端应用程序的最终重定向中，因此客户端应用程序可以检查熵是否与其在本地保存的内容（或仅在安全的HTTP cookie中）匹配，并确定已启动授权请求，因为攻击者无法在状态参数中设计带有熵的URL，该URL会与客户端应用程序保留的内容匹配。