我在我的网络应用程序中使用 csrf 保护。
现在我计划触发 OAuth2 授权代码授予工作流，从使用window.open(myOAuth2StartEndpoint?oauthstuff&state=mystate).
但是在这种情况下，mystate变量在启动工作流时暴露在静态href标签中，我想知道将我的默认 csrf 令牌暴露为是否危险mystate？我可以在里面做一个csrf检查myOAuth2StartEndpoint，所以令牌不是免费暴露的，但这够了吗？
如果没有，是否有关于如何处理这种情况的建议？
免责声明：找不到有关该主题的任何参考资料，因此我将使用一个名为“逻辑”的可疑工具。如果有人找到任何好的参考，请添加它们。
CSRF 很危险
毫无疑问，OAuth2 也不例外。事实上，在使用 OAuth2 时，您可以通过多种方式利用 CSRF 攻击。原因是发送的多条消息可用于触发 CSRF 攻击。OAuth2 Spec 第 10.12 节很好地概述了您可以使用 CSRF 做什么
但是，让我们看看当用户想要使用 OAuth2 登录时会发生什么。在我们的示例中，我们将有以下参与者：
然后，让我们从用户的角度来看看当他尝试向提供者进行身份验证时会发生什么。
我们可以攻击哪里？
从用户的角度来看，这只是两个简单的步骤，但有多个地方可以攻击它。这里的根本问题之一是，如果您已经登录，OAuth2 提供程序通常会自动重定向您。一个很好的例子是 stackoverflow。有关详细信息，请参阅此答案：
所以不同的攻击是：
攻击者可以用他自己的授权码替换授权码，让您登录他的帐户而不是您的帐户。可能看起来很疯狂，但如果您决定在他的帐户中输入一些机密信息，他现在可以访问它。例如：银行信息
攻击者可以在他的机器上生成一个有效的提供者链接，然后将其提供给您，如果提供者自动重定向，那么您将登录到攻击者想要攻击的服务。
攻击者让您从客户端网站生成有效的提供者链接（仅当链接是通过静态 URL 上的 post/get 生成时才有效），然后如果提供者自动重定向，您将登录到攻击者的服务想要攻击。
如何防范它们？
很简单，你只需要在 OAuth2 的 state 参数中传递你的 CSRF 防伪令牌来防止 #1 和 #2。然后，为了防止＃3，您需要确保在没有用户交互的情况下无法生成链接，这意味着使用 CSRF 保护来保护该链接。但回到＃1和＃2......
通过包含一个 CSRF 令牌作为状态，您将击败这些攻击，因为攻击者不可能为您提供不是您自己生成的链接。CSRF 令牌的一个简单实现是一个随机数，它存储在会话中，然后包含在用户发送的每个表单中。如果表单包含令牌，客户端认为它是有效的。如果它不包含它，则客户端假定该请求无效。
通常，该 CSRF 令牌只能由用户/浏览器和客户端访问，但在 OAuth2 的情况下，更多方可以访问它。要了解要做什么，我们需要知道哪些是这些附加方。
答案：只需发送令牌
因此，在这种情况下，令牌将已知
这是通过 HTTPS 进行的简单往返。攻击者无法将自己插入该对话中，因此您无需担心。
您是否需要保护令牌免受提供商的侵害？
不会。如果 OAuth2 提供程序是恶意的，那么您已经丢失了。如果他愿意，他不需要您的 CSRF 令牌来接管您的所有帐户。当您选择使用 OAuth2 时，您基本上使他成为您所有用户帐户的上帝。
结论
不要太担心如何发送 CSRF 令牌；只要确保你发送它。此外，它作为 url 参数发送的事实将是另一个担心永久密码的问题，但由于这些令牌是临时的，所以应该不是什么大问题。
state 是由 RP（资源提供者）传递给 IP（身份提供者）的信息，并且预计 IP 将发回相同的信息。
在我的例子中，我state在我的JavaEE OpenID Connect 实现中使用了相对于在显示 OP 登录屏幕之前在 RP 上最初请求的 URL 的应用程序 URL。
我使用对称密码保护它，然后使用 base64url 对其进行编码。连同验证它是一个有效的 URL 并且在针对应用程序的根目录解析时相对于应用程序的根目录。对称密钥是随机的，不会在 RP 之外传递。
如果我想要一个更安全的实现（但仅限于支持 nonce 的 IP），我会将源 URL 和 anonce一起编码，并确保提取解码的 nonce 值。在nonce可以作为盐。
其他 IP 可能会将不同的state值发送回 RP。虽然这通常意味着有非标准数据由 RP 传递到 IP 并且它们相互理解。例如，state可以传递辅助节点，并且根据 IP 处理，它可以在需要时发送其他状态。