绕过经过身份验证的 XmlHttpRequest 的同源策略

发布于 2024-12-14 07:02:13 字数 795 浏览 0 评论 0原文

我在 foo.com 上有一个网站,提供 PageA 服务。

PageA 中包含一些 JQuery,它们通过 XmlHttpRequest 从位于 bar.com 的 CouchDb 实例请求一些 JSON 数据。

据我了解,同源策略可以防止这种情况发生,但使用 JSONP 应该可以规避此限制(我相信 CORS 最终将覆盖此用例。)

foo.com 背后的服务器有一个值得信赖的服务器连接到 bar.com 上的数据库。

是否可以让用户使用其 OAuth 凭据(例如 Twitter 登录)通过 foo.com 进行身份验证,然后进行身份验证以使用 bar.com? (我认为这不是因为身份验证 cookie 只能由 foo.com 读取。)

鉴于此,是否有任何方式可以验证用户在 < code>bar.com 来自 foo.com 使用 CouchDB 的任何可用身份验证机制(OAuth、cookie 和 Basic)?

编辑:例如,我可以从 foo.com 返回 bar.com 的用户凭据(通过其可信链接检索),然后在 XmlHttpRequest HTTP 标头中设置客户端,以使用 bar.com 进行基本身份验证。当然,这一切都是通过 TLS 完成的(...或者这是一场安全噩梦?)

I have a website on foo.com serving PageA.

PageA has some JQuery within it that requests via XmlHttpRequest some JSON data from a CouchDb instance residing at bar.com.

As I understand it the same origin policy prevents this, but the use of JSONP should circumvent this limitation (CORS will eventually cover this use-case, I believe.)

The server behind foo.com has a trusted connection to the database at bar.com.

Is it possible to have a user authenticate with foo.com using their OAuth credentials (Twitter login, for example), and subsequently be authenticated to use bar.com? (I presume not due to the authentication cookie only being readable by foo.com.)

Given this, is there any way I can authenticate a user to use the CouchDB at bar.com from foo.com using any of the available authentication mechanisms for CouchDB (OAuth, cookie and Basic)?

Edit: could I, for example, return user credentials for bar.com from foo.com (retrieved via its trusted link) which are then set client-side in the XmlHttpRequest HTTP header for basic authentication with bar.com. All done over TLS of course (...or is this a security nightmare?)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

农村范ル 2024-12-21 07:02:13

从我的观点来看,即使 JSONP 也是一个安全风险 - 所以我不会走这条路......

为了实现你所要求的,我看到两个选项(如果需要的话,两者都可以与 SSL 一起使用!):

  • < p>编写一个在 foo.com 上运行的自定义 Webservice/REST/SOAP/任何内容,并代表您与经过身份验证的客户端的 bar.com 进行交互

  • 使用在 foo.com 上运行的“通用 http 代理” code> 并映射 bar.com,您的应用/页面的工作方式就像 CouchDB 在 bar.com 上运行,对于经过身份验证的客户端

From my POV even JSONP is a security risk - so I just wouldn't go down that path...

To achieve what you are asking for I see two options (both can be made to work with SSL if need be!):

  • write a custom webservice/REST/SOAP/whatever which runs on foo.com and interacts on your behalf with bar.com for authenticated clients

  • use a "generic http proxy" which runs on foo.com and maps bar.com in a way that your app/page works as if the CouchDB is running on bar.com for authenticated clients

末骤雨初歇 2024-12-21 07:02:13

关于 xhr 中的同源政策,我也遇到了同样的问题。我有一个网站,我想使用来自运行 CouchDB 的不同服务器的 JSON 数据填充自动完成内容。

有两种方法:

  1. JSONP - 这可以通过主 Web 服务器很好地
  2. 代理 CouchDB - 从客户端 b/c 的角度来看,这非常有效,所有内容都在同一主机上。它还使 SSL 变得可行。

至于从 CouchDB 和另一个应用程序服务器共享登录会话,我不知道如何在不诉诸基本 HTTP 身份验证的情况下做到这一点,这并不是那么安全。让应用程序服务器充当中间人 b/t 客户端和 CouchDB 可能会更好。

应用程序服务器中间人的另一个好处是单个 CouchDB 数据库可以包含多个用户的文档。相比之下,如果客户端直接访问 CouchDB,您可能需要通过过滤复制为每个用户创建一个单独的数据库,以便一个用户无法查看另一个用户的文档。

I had the same issue regarding same origin policy in xhr. I had a website and I wanted to populate autocomplete content with JSON data from a different server running CouchDB.

There are 2 ways:

  1. JSONP - this works just fine
  2. proxy CouchDB through main web server - this works great from point of view of client b/c everything is on the same host. It also makes SSL doable.

As far as sharing a login session from CouchDB and another app server, I don't know how to do that without resorting to basic HTTP authentication, which isn't really that secure. It is probably better to let app server act as middle-man b/t client and CouchDB.

Another benefit of an app server middle-man is that a single CouchDB database can have documents for multiple users. By contrast, if the client accesses CouchDB directly, you probably need to create a separate database for each user via filtered replication so that one user cannot view another user's documents.

白芷 2024-12-21 07:02:13

您可以从 facebook 身份验证服务器流程中获得启发,用客户端代替您的客户端,用服务器代替 foo.com,用 facebook 代替 bar.com。请参阅 http://developers.facebook.com/docs/authentication。这样客户端应该已经过身份验证,可以使用来自 bar.com 的数据(当然,在从 bar.com 加载的脚本中,但是您可以将数据传递给来自 foo.com 的回调,除非我弄错了)。

You can inspire from facebook authentication server-flow, substituting client for your client, server for foo.com and facebook for bar.com. Look at http://developers.facebook.com/docs/authentication. That way client should have been authenticated to use data from bar.com (in script loaded from bar.com, of course, but you can pass data to callback from foo.com, unless I am mistaken).

小矜持 2024-12-21 07:02:13

据我了解,您希望使用 foo.com 中的 JSONP 在 bar.com 上发出请求,同时希望 bar.com 能够知道该请求是否已通过 foo.com 身份验证。

这就像登录 foo.com 并允许将真实性转移到 bar.com 一样。

假设 XMLHttpRequest 可以记住其余请求的 cookie 中的会话 ID,那么如何使用一次性密码(实际上是一个随机字符串,我们可以将其称为令牌)从页面调用 bar.com登录后由 foo.com 生成,如下所示:

login request -> foo.com -> XHR(bar.com, OTP) -> bar.com
cookie updated with an active session id <- bar.com
XHR(bar.com, CounchDB) -> bar.com successfully

因此,如果 foo.com 和 bar.com 可以私下(并且安全!)进行通信,则 foo.com 可以生成 OTP 并将其传递给 bar.com,以便 bar.com 知道只有有效的用户才能知道它,因此可以将会话 ID 视为已验证。

替代课程:

  1. 如果 XMLHttpRequest 使用到 bar.com 的 cookie 在请求之间不持久,则必须在每个请求中传输相同的 OTP。
  2. bar.com 必须提供一项服务来监控来自 foo.com 的新添加 OTP 的身份验证授权。它应该有一些超时机制来使旧令牌失效。
  3. bar.com可能还需要提供身份验证删除服务,以防止使用公共机器时的风险。

As I understand you wish to use JSONP from foo.com to make requests on bar.com while want bar.com to be able to know if this request is already authenticated by foo.com or not.

This is like logging in on foo.com and allowing the authenticity to be transferred to bar.com.

Assuming that the XMLHttpRequest could remember the session id in the cookie of the rest requests, how about using a One-Time Password (in fact a random string, we may call it a token) that made a call to bar.com from the page generated by foo.com after logged in depicted as below:

login request -> foo.com -> XHR(bar.com, OTP) -> bar.com
cookie updated with an active session id <- bar.com
XHR(bar.com, CounchDB) -> bar.com successfully

So if foo.com and bar.com can communicate privately(and securely!), foo.com can generate a OTP and pass this to bar.com so that bar.com knows that only the valid user can know it and therefore can treat the session id as authenticated.

Alternative courses:

  1. If the cookie used by XMLHttpRequest to bar.com doesn't persist across requests, the same OTP has to be transferred in each requests.
  2. bar.com has to provide a service to monitor for authentication authorization from foo.com for newly added OTP. It should have some time out mechanism to invalidate old tokens.
  3. bar.com may also need to provide an authentication removal service as well to prevent the risks when using public machines.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文