AJAX withCredentials不会在Safari中传递Cookie [英] AJAX withCredentials not passing along cookies in Safari

查看:291
本文介绍了AJAX withCredentials不会在Safari中传递Cookie的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I have a single-page static app hosted at example.com. My server for the app is hosted at server.com. I keep these two services completely separate and they can scale differently this way. When the user wants to login their username and password is passed to yoyoma.com and a cookie is set on server.com with the access_token. The user is then redirected to example.com and is now logged in.

从example.com的静态应用中,我们现在可以向server.com设置发出AJAX请求。 withCredentials = true,以便将我们设置的access_token传递到server.com。在Safari之外的所有浏览器中,它都能完美运行。使Safari正常运行的唯一方法是进入首选项->隐私->禁用防止跨站点跟踪。我知道cookie是在server.com上设置的,但不会随AJAX请求一起传递。苹果公司认为这似乎是一些隐私功能很棒,但是您应该如何解决此问题。我不是广告服务,我没有做任何恶作剧,只是想让我的应用正常工作。我特别想在服务器位于不同域的情况下构建一个单页应用程序。

From the static app at example.com, we can now make AJAX requests to server.com setting withCredentials=true so that the access_token we set is passed along to server.com. This works perfectly in every browser but Safari. The only way I've gotten Safari to work is by going to preferences -> privacy -> disabling "Prevent cross-site tracking". I know that the cookies are getting set on server.com, but they don't get passed with the AJAX request. It seems to be some Privacy feature that Apple thinks is just wonderful, but how are you supposed to get around this issue. I'm not an ad service, I'm not doing anything evil, just trying to get my app to work. I specifically want to build a single page app where the server is on a different domain. Is this possible in Safari or has their privacy setting made this impossible?

注意:我还应该向安全狂热者提及,当设置了access_token cookie时,用户可以使用CSRF令牌重定向到example.com。标题会在每个AJAX请求中传递此csrf令牌,以防止跨站点请求伪造。

Note: I should also mention to security fanatics that when the access_token cookie is set, the user is then redirected to example.com with a CSRF token. This csrf token is passed in every AJAX request by a header to prevent Cross Site Request Forgery.

推荐答案

假设您已设置为保留不同的域-并非没有道理,有一些方法可以解决它,但是它们带有折衷办法

Assuming you're set on keeping different domains - which is not at all unreasonable there are some ways to tackle it, but they come with compromises

1
拥有 example.com 重定向到呈现为 server.com/login 的服务器,以创建 httpOnly Cookie,然后将其重定向回您的SPA中的登录状态。

1 Have example.com redirect to a server rendered server.com/login for creating the httpOnly cookie and then redirect them back to their logged in state in your SPA.

据我了解,当在Safari中启用 Prevent跨站点跟踪时,其目的是用户在允许发送Cookie之前与其他域进行交互。
通过重定向它们,已经创建了该意图,并且您应该没有问题设置cookie,并由 example.com 发送它。

As I understand it, when Prevent cross-site tracking is enabled in Safari, the intention is to have the user interact with the other domain before cookies are allowed to be sent. By redirecting them, that intent has been created and you should have no issue setting a cookie and have it be sent by example.com.

不过,它确实有其自身的局限性

However it does come it its own set of limitations

了解更多信息

2
查看与 StorageAccess ,因为此处的想法是与依赖于来自不同域的cookie的第三方身份验证解决方案一起使用。 Safari ITP使得这些功能变得更难使用,因此其想法是与供应商合作,以提供比 LocalStorage 更好的解决方案。

2 Look into the discussion related to StorageAccess as the idea here is to work with third party auth solutions that rely on cookies from different domains. Safari ITP has sorta made those harder to use, so the idea is to work with vendors for a better solution than LocalStorage.

3
将密钥存储在 LocalStorage 中,然后审核所有来自您的正在运行的javascript代码并在处理用户创建的值时,请务必遵循最佳做法。

3 Store your key in LocalStorage, and vet all running javascript code coming from you and make sure to follow best practices when it comes to dealing with user created values.

LocalStorage 使您可能遭受XSS攻击,但Cookies使您遭受CSRF攻击。您必须减轻这些负担,而且并不太难,但是请记住,在使用Cookie时您已经引入了这些向量。

LocalStorage exposes your to potential XSS, but Cookies expose you to CSRF attacks. You have to mitigate those and it's not too hard, but keep in mind you introduced those vectors when cookies were used.

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

Any XSS that happens is game over, even with httpOnly cookies. Forget your auth key, running the attackers code can do so much more damage.


  • 键盘记录器使用用户名/密码

  • 如果攻击在身份验证后发生,他们可能会弹出一个模式,要求重新身份验证。

  • 提交更改电子邮件的请求,然后要求重设密码

没收到我错了,将 LocalStorage 作为一般攻击转储起来比上面列出的攻击更容易

Don't get me wrong, it's easier to dump LocalStorage as a generic attack versus the attacks listed above

最终,您在处理Cookie问题上所花费的资源最好用于强化在用户浏览器上运行的javascript,以确保它们没有运行恶意代码

That being said, in the end the resources you spend on dealing with cookie issues, could be better spent hardening down your javascript running on the users browsers to ensure they aren't running malicious code

但是不能保护它们不受扩展名的影响, httpOnly cookie至少将确保它们的密钥不会泄漏。了解您的妥协。

You can't protect them from extensions though, and a httpOnly cookie would at the very least ensure that their keys aren't leaked. Know your compromises.

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

Keep in mind that whatever approach you're taking, any further reliance on browser needs to think through the different versions of browsers out in the wild. As an example, don't assume using httpOnly cookies and setting a sameSite policy negates the need for a CSRF token. Any addition of cookies might s till need a CSRF token as a header as of today unless it's a controlled environment.

松散持有的个人意见。
无害。 Cookies增加了您必须减轻的危害 /工作。
Cookies可以保护泄漏访问令牌的攻击,但是为什么攻击者可以在运行希望的任何代码时关心访问令牌?
LocalStorage的弱点是XSS,但Cookies不能防止这种情况。

Personal Opinion held loosely. Do no harm. Cookies add "harm"/work that you have to mitigate. Cookies might protect attacks leaking access tokens but why would an attacker care about the access token when they can run any code they wish? LocalStorage weakness is XSS, but Cookies does not protect against that.

是什么阻止他们仅使用密码?
弹出一个登录模式,通知一个不会三思而后行的意外用户,地狱Github出于某些原因不时地这样做,这并非闻所未闻。

What prevents them from just taking the password? Popping up a login modal to an unexpected user that won't think twice, hell Github does that from time to time for good reasons, it's not unheard of.

这篇关于AJAX withCredentials不会在Safari中传递Cookie的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆