【问题标题】:What is the threat model for the same origin policy?同源策略的威胁模型是什么?
【发布时间】:2011-10-08 07:50:51
【问题描述】:

http://en.wikipedia.org/wiki/Same_origin_policy

同源策略可防止一个站点的脚本与另一个站点通信。 Wiki 说这是一个“重要的安全概念”,但我不清楚它可以防止什么威胁。

我了解来自一个站点的 cookie 不应与另一个站点共享,但可以(并且现在)单独执行。

CORS 标准http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing 提供了绕过同源策略的合法系统。据推测,它不允许同源策略旨在阻止的任何威胁。

看看 CORS,我什至不清楚谁受到了保护。 CORS 由浏览器强制执行,因此它不会保护任何一个站点免受浏览器的影响。并且限制是由脚本要与之交谈的站点决定的,因此它似乎并不能保护用户免受任一站点的影响。

那么,什么是同源政策?

【问题讨论】:

    标签: xss security same-origin-policy cors


    【解决方案1】:

    同源策略的目的是避免恶意站点M从受信任站点A读取信息的威胁使用A用户的权限(即授权cookie)时间>。这是一个浏览器策略,而不是服务器策略或 HTTP 标准,旨在降低另一个浏览器策略的风险——在联系站点 A 时从站点 A 发送 cookie。

    请注意,没有什么可以阻止M 在浏览器之外访问A。它可以发送任意数量的请求。但它不会在 A 的不知情用户的权限下这样做,否则浏览器中可能会发生这种情况。

    另请注意,该策略阻止M 页面读取来自A。它不会保护A 服务器免受请求的影响。特别是,浏览器将允许从MA 的跨域POSTS(cookie 和所有)。该威胁称为Cross-Site Request Forgery;同源政策不会缓解这种情况,因此必须提供额外的措施来防止这种情况发生。

    【讨论】:

      【解决方案2】:

      文章@EricLaw 提到,“Same Origin Policy Part 1: No Peeking”很好。

      以下是为什么我们需要“同源策略”的简单示例:

      可以使用 iframe 在您自己的网页中显示其他网页(“内嵌框架”将另一个 HTML 文档放在一个框架中)。假设您显示 www.yourbank.com。用户输入他们的银行信息。如果您可以阅读该页面的内部 HTML(这需要使用脚本),您可以轻松阅读银行帐户信息,并且繁荣。安全漏洞。

      因此,我们需要同源策略来确保一个网页不能使用脚本读取另一个网页的信息。

      【讨论】:

        【解决方案3】:

        例如,它会阻止 Farmville 检查您银行帐户的余额。或者,更糟糕的是,弄乱您将要发送的表格(在输入 PIN/TAN 之后),这样他们就可以拿到所有的钱。

        CORS 主要是用于确定自己不需要这种保护的网站的标准。它基本上说“任何网站的脚本都可以与我交谈,没有安全可能被破坏”。因此,它确实允许在不需要保护且跨域网站有益的地方进行 SOP 禁止的事情。想想网格。

        【讨论】:

        • 在不访问 cookie 的情况下如何做到这一点?还是我对受保护的 cookie 有误?
        • 通过将 withCredentials 请求属性设置为 true,可以将 Cookie 与 CORS 请求一起发送。因为 JavaScript 无论如何都可以访问 cookie,所以在那里建立额外的障碍没有任何好处。关于这个主题的一个很好的阅读是在这里:hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors
        猜你喜欢
        • 2011-08-28
        • 2018-06-27
        • 2010-12-22
        • 1970-01-01
        • 1970-01-01
        • 2015-05-23
        • 1970-01-01
        • 2011-03-03
        • 1970-01-01
        相关资源
        最近更新 更多