15

当使用 Google Chrome（最新）构建 27 Win7/PC 阻止第 3 方 cookie 时，我发现几乎所有来自其他站点的 OAuth 登录都不起作用，除了使用 G+ 登录。不过我已经用谷歌登录了，所以这个 cookie 是存在的。

  • 这种行为实际上是 OAuth2.0 的依赖项，需要启用 3rd-party cookie 吗？
  • 这是 OAuth 普遍实施的结果吗？
  • 这是依赖于客户的东西吗？
  • 这是由 Chrome 定义什么是“第三方 cookie”造成的吗？

感谢大家的帮助和时间！我似乎找不到任何可以为我澄清问题的来源。

4

1 回答 1

1

对于 Web 应用程序，作为防御跨站点请求伪造 (CSRF) 的一部分，OAuth 2.0 规范需要某种类型的存储本地存储（“必须...”）。该规范特别建议使用 cookie 或 HTML5 本地存储，正如您的观察所示，cookie 是一种流行的实现方式。

参考RFC 6749 -我们发现的 OAuth 2.0 授权框架（强调添加）：

  1. 安全注意事项

作为一个灵活且可扩展的框架，OAuth 的安全考虑取决于许多因素。以下部分为实施者提供了安全指南，重点关注第 2.1 节中描述的三个客户端配置文件：Web 应用程序、基于用户代理的应用程序和本机应用程序。

...

10.12。跨站请求伪造

跨站请求伪造 (CSRF) 是一种攻击，其中攻击者导致受害者最终用户的用户代理遵循恶意 URI（例如，作为误导性链接、图像或重定向提供给用户代理）到信任服务器（通常通过有效会话 cookie 的存在建立）。

针对客户端重定向 URI 的 CSRF 攻击允许攻击者注入其自己的授权代码或访问令牌，这可能导致客户端使用与攻击者的受保护资源相关联的访问令牌，而不是受害者的（例如，保存受害者的银行帐户信息）到攻击者控制的受保护资源）。

客户端必须为其重定向 URI 实施 CSRF 保护。 这通常通过要求发送到重定向 URI 端点的任何请求包含一个将请求绑定到用户代理的已验证状态的值（例如，用于验证用户代理的会话 cookie 的哈希）来完成。客户端在发出授权请求时应该使用“state”请求参数将此值传递给授权服务器。

一旦从最终用户获得授权，授权服务器将最终用户的用户代理重定向回客户端，并使用“state”参数中包含的所需绑定值。绑定值使客户端能够通过将绑定值与用户代理的身份验证状态匹配来验证请求的有效性。 用于 CSRF 保护的绑定值必须包含一个不可猜测的值（如第 10.10 节所述），并且用户代理的身份验证状态（例如，会话 cookie、HTML5 本地存储）必须保存在只有客户端可访问的位置和用户代理（即受同源策略保护）。

于 2017-05-28T20:44:08.547 回答