【问题标题】:About same-origin limitation on XMLHttpRequest关于 XMLHttpRequest 的同源限制
【发布时间】:2012-04-21 03:23:13
【问题描述】:

我认为XMLHttpRequest 的同源限制有一些我不明白的地方。

与其禁止 Javascript 代码向不同的主机发送 http 请求(这对于合法使用来说确实很烦人),在这种情况下只允许请求但不发送或接受 cookie 不是更好吗?

禁止使用特定脚本来获取互联网上其他所有人都可以获取的内容,乍一看在我看来,这是一个非常奇怪的选择...

我错过了什么?

【问题讨论】:

    标签: javascript xmlhttprequest same-origin-policy


    【解决方案1】:

    与其禁止 Javascript 代码向不同的主机发送 http 请求(这对于合法使用来说确实很烦人),在这种情况下只允许请求但不发送或接受 cookie 不是更好吗?

    这就是Cross-Origin Resource Sharing (CORS) 指定的内容。

    在使用用户凭据发出跨域请求时,应用程序必须始终小心,处理此类请求的服务器必须小心使用凭据,包括 Origin 标头。

    1. 当请求具有检索以外的意义时,并且当依赖 Origin 标头作为凭据时,服务器必须小心区分授权请求和授权访问响应中的资源表示。

    ...

    omit credentials flag

    设置何时在请求中排除用户凭据以及何时在其响应中忽略 cookie。


    禁止使用特定脚本来获取互联网上其他所有人都可以获取的内容,乍一看在我看来,这是一个非常奇怪的选择...

    我错过了什么?

    网络标准机构花了一段时间才意识到人们想要编写严肃的 JavaScript 繁重的应用程序。 Gmail 改变了这一切,但像 W3C 这样的标准机构需要一段时间来填补功能漏洞。

    【讨论】:

      【解决方案2】:

      您的建议最初会避免用户数据被利用,但这仍然意味着代码可以从任何其他潜在的恶意域运行,然后可以读取和传输该 cookie 数据,而不会在请求中隐式发送.我想现在的情况是安全性和灵活性之间的最佳折衷。

      【讨论】:

      • 我明白你的意思......但是,当安全性基于用户代理需要执行的检查时,我往往会感到不舒服。在我的薄箔帽下,我什至可以听到一个声音说,在用户端推动安全性在技术上是无稽之谈,但在战略上很重要,以便能够在未来声称您需要控制允许用户端运行的内容。跨度>
      猜你喜欢
      • 1970-01-01
      • 2011-11-19
      • 2013-11-09
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2010-12-22
      • 2016-09-16
      • 1970-01-01
      相关资源
      最近更新 更多