Cookies 为什么可以将授权代码流的状态参数存储在cookie中？

在常规web应用程序中实现授权代码流时，允许在Cookie中存储状态参数。请参阅和[此处]（）

为什么在cookie中存储状态（也称为nonce）是一种可接受的解决方案？例如，如果我们在nodejs中执行此操作，代码将如下所示

  app.use('/login', (_req, res) => {
    state = randomString(32)
    const authorizationEndpointUrl = new URL(`${activeConfig.authorization.domain}/authorize`);
    authorizationEndpointUrl.search = new URLSearchParams({
      audience: activeConfig.authorization.audience,
      response_type: 'code',
      redirect_uri: 'http://localhost:8443/callback',
      client_id: activeConfig.authorization.clientId,
      scope: activeConfig.authorization.scope,
      state,
    }).toString();
    res.cookie('state', state, { httpOnly: true }); // cookie set here
    res.redirect(authorizationEndpointUrl.toString());
  });

  app.use('/callback', req => {
     // check that url state matches req.cookie.state???
  })

---

但是如果我们这样做，有什么能阻止攻击者在响应url和cookie中设置相同的“假”状态呢？我这里缺少什么？

用于跟踪状态的cookie不应该是可以伪造的。客户机应至少对其进行签名，以便只有客户机自己才能生成它。

---

在这一点上，只有当攻击者恰好在生成请求之后和返回合法响应之前访问该设备时，才能够重播此类cookie，而不是伪造来自任意设备的未经授权的响应

根据您发布的链接，状态参数（nonce）应作为url参数添加到请求中。oauth将根据url参数而不是cookie进行验证。因此，将nonce存储在cookie中应该不是问题，它不是在cookie中查找nonce。我认为重点在于，攻击者不知道能够创建url参数的nonce。你把钱放在哪里并不重要

---

他们称之为“国家”令人困惑。它专门用于CSRF攻击。不要与oauth标记混淆。这些已经加密。

不确定“如果在生成请求之后，在返回合法响应之前，他们恰好可以访问设备，则重播此类cookie”是什么意思，即使我对其进行了签名，所有这些都只是验证cookie的真实性。攻击者仍然可以重播以前的状态字符串，对吗？我不知道如何防止重播伪造保护措施。如果我们将nonce存储在Redis中，那么我们就可以安全地进行回放，因为每个nonce只能使用一次，因为我可以在验证后将其从Redis中删除。我怎样才能用cookie实现同样的结果呢？使用状态并不是为了防止重播，而是为了防止伪造。重播还有其他措施：例如，客户端可以在收到状态匹配的响应后立即删除状态跟踪cookie；每个后续请求都无法工作，因为它们不会伴随状态跟踪cookie。或者，客户机可以维护一个它所看到和处理的授权代码的缓存，拒绝任何进一步的使用。如果将状态值存储在reddis中，则不会将事务绑定到特定的用户代理实例，这会打开不同的攻击场所。真的吗？nonce是重播攻击的常用补救方法。加上auth0甚至说，不匹配的状态表示“对未经请求的请求的响应”。“每个后续请求都不起作用，因为它们不会伴随状态跟踪cookie。”不确定这里的意思。攻击者不能只在响应url+cookie中包含一个旧的nonce吗？对不起，我不想和你说的一切抗争。老实说，我还是很困惑。不用担心：）“未经请求的请求”正是我所说的“伪造”。如果攻击者偷走了cookie，那么您正在处理的攻击不是伪造的，而是重放——对策是让请求单次使用：这是用我前面提到的缓存之类的东西实现的，它可以绑定到识别请求的任何东西上（如authz代码或状态值本身）。“我前面提到的缓存，它可以绑定到任何标识请求的东西上（比如authz代码或状态值本身）。“好的，明白了。那么，仅仅使用cookies就不可能强制执行这种单一使用吗？OpenId规范是否有意同意这一点，因为他们的目标是防止伪造，而不是重播。换句话说，在Redis中存储nonce会比cookie更好，但从规范的角度来看，这并不重要，因为目标是防止伪造而不是重放？“我认为，攻击者不知道nonce，因此无法创建url参数，这是关键。存储nonce的位置并不重要。”但是，如果我将其存储在res.cookie中，攻击者难道不能查看传出的重定向请求并查看nonce是什么吗？我觉得我在这里误解了一些非常基本的东西。记住，这是用于跨站点攻击的。生成伪造请求的站点将无法访问目标域的cookie数据。目标域将查找url中的nonce，而不是发送给它的cookie。“目标域将查找url中的nonce，而不是发送给它的cookie。”我想我需要同时查找这两个字段以确保它们匹配？“生成伪造请求的站点将无法访问目标域的cookie数据。”好的。你是说我不应该担心重播攻击，因为攻击者无法设置cookie？CSRF是一种非常特殊的攻击。查看维基百科：如果你不允许在api上使用CORS，我不认为这有什么好担心的。我不知道你说的重播攻击是什么意思。只要您使用SSL，就应该没有人能够看到cookie/令牌，只有授权客户端才能看到。