AJAX withCredentials 未在 Safari 中传递 cookie

Question

我在 example.com 上托管了一个单页静态应用程序。我的应用程序服务器托管在 server.com 上。我将这两个服务完全分开，它们可以通过这种方式进行不同的扩展。当用户想要登录时，他们的用户名和密码被传递到 yoyoma.com，并在 server.com 上设置一个带有 access_token 的 cookie。然后用户被重定向到 example.com 并且现在已经登录。

从 example.com 上的静态应用程序，我们现在可以向 server.com 发出 AJAX 请求，并设置 Credentials=true，以便我们设置的 access_token 传递给 server.com。这在除 Safari 之外的所有浏览器中都能完美运行。我让 Safari 工作的唯一方法是转到首选项 -> 隐私 -> 禁用“防止跨站点跟踪”。我知道 cookie 是在 server.com 上设置的，但它们没有通过 AJAX 请求传递。这似乎是苹果认为非常棒的一些隐私功能，但你应该如何解决这个问题。我不是广告服务，我没有做任何坏事，只是想让我的应用程序正常工作。我特别想构建一个单页应用程序，其中服务器位于不同的域中。这在 Safari 中是否可行，或者他们的隐私设置使这变得不可能？

注意：我还应该向安全狂热者提一下，当设置 access_token cookie 时，用户会被重定向到带有 CSRF 令牌的 example.com。此 csrf 令牌通过标头在每个 AJAX 请求中传递，以防止跨站点请求伪造。

Answer 1

假设您打算保留不同的域 - 这一点也不无道理，有一些方法可以解决它，但它们会带来妥协

1 让example.com 重定向到呈现server.com/login 的服务器以创建httpOnly cookie，然后将它们重定向回您的SPA 中的登录状态。

据我了解，当在 Safari 中启用 Prevent cross-site tracking 时，目的是让用户在允许发送 cookie 之前与其他域进行交互。 通过重定向它们，该意图已创建，您应该可以毫无问题地设置 cookie 并将其由example.com 发送。

但它确实有其自身的限制

Read more

2 查看与StorageAccess 相关的讨论，因为这里的想法是使用依赖于来自不同域的 cookie 的第三方身份验证解决方案。 Safari ITP 使这些变得更难使用，因此我们的想法是与供应商合作以提供比LocalStorage 更好的解决方案。

3 将您的密钥存储在 LocalStorage 中，并审查您提供的所有正在运行的 javascript 代码，并确保在处理用户创建的值时遵循最佳实践。

LocalStorage 将您暴露给潜在的 XSS，但 Cookie 将您暴露于 CSRF 攻击。您必须减轻这些问题，这并不难，但请记住，您在使用 cookie 时引入了这些向量。

任何发生的 XSS 都会结束，即使使用 httpOnly cookie。忘记您的身份验证密钥，运行攻击者代码会造成更大的破坏。

• 键盘记录器获取用户名/密码
• 如果攻击发生在经过身份验证的状态之后，他们可能会弹出一个询问重新身份验证的模式。
• 提交更改电子邮件的请求，然后请求重置密码

不要误会我的意思，将LocalStorage 转储为通用攻击与上面列出的攻击相比更容易

话虽如此，最终您花在处理 cookie 问题上的资源最好花在强化在用户浏览器上运行的 javascript 以确保它们没有运行恶意代码

但是，您无法保护它们免受扩展的影响，httpOnly cookie 至少可以确保它们的密钥不会泄露。了解你的妥协。

编辑：请记住，无论您采用何种方法，对浏览器的任何进一步依赖都需要考虑不同版本的浏览器。例如，不要假设使用httpOnly cookie 并设置sameSite 策略会否定CSRF 令牌的需要。从今天开始，任何添加的 cookie 都可能需要 CSRF 令牌作为标头，除非它是受控环境。

个人意见松散。 不要伤害。 Cookie 会增加您必须减轻的“伤害”/工作。 Cookie 可以保护泄漏访问令牌的攻击，但是当攻击者可以运行任何他们希望的代码时，为什么还要关心访问令牌呢？ LocalStorage 的弱点是 XSS，但 Cookies 不能防止这种情况。

是什么阻止他们获取密码？ 向一个不会三思而后行的意外用户弹出登录模式，地狱 Github 不时这样做是有充分理由的，这并非闻所未闻。