Silverlight、Flash和Javascript跨域策略

有点模糊的问题：

这个问题源于使用MediaStreamSource作为MediaElement源在Silverlight中使用非asf流的尝试。事实证明，这里的跨域问题非常令人沮丧

通常，不允许在web上进行域之间的通信

如果我理解正确，比如说恶意站点/嵌入对象A可以向用户碰巧登录的站点B发送请求，发送验证cookie，然后坏事就发生了

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

一个更好的解决方案不是禁止从a->B发送cookie，而不是禁止所有通信吗

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

滥用身份验证cookie（XSRF，某些XSS场景）只是问题的一部分。通过querystring将信息从“好”网站发送到“坏”网站也非常容易（例如，从银行页面抓取一些数据，通过包含

---

阻止Cookie可能会限制从坏站点到好站点的访问，但您还必须防止脚本注入或其他攻击暴露受信任站点中的数据，然后这些数据可以传输到坏站点，而这不需要Cookie。

跨域策略背后的原因不仅仅是Cookie/会话本身在web内容只是“哑”HTML和图像的时代，如果站点B显示的页面加载了来自站点a的图像，那么就没有真正的安全问题。如果存在非安全问题（比如出于IP原因想要阻止热链接），服务站点可能需要一个会话或类似的东西。但现在web资产包括可编写脚本的东西，如Flash、SilverLight、JS、iFrame和二进制流（可以是任何内容），如果这些资产在另一个站点的页面中显示时仍保持脚本可访问性，那么安全风险就太大了

因此，跨域策略基本上反映了这样一种让步，即期望站点通过手动阻止对活动资产的访问来“选择退出”此类风险是不合理的（如果他们想要阻止热链接图像，或者要求对某些页面进行会话，他们必须这样做）。该负担与更安全案例的违约相反，因此服务站点必须“选择”此类风险，具体方式是选择跨域提供哪些资产，以及向谁提供这些资产