我最近在多个页面上都看到了XSSI，例如Web Application Exploits and Defenses：
浏览器阻止一个域的页面读取其他域的页面。但是它们不会阻止域的页面引用其他域中的资源。特别是，它们允许从其他域渲染图像，并从其他域执行脚本。包含的脚本没有自己的安全上下文。它在包含它的页面的安全上下文中运行。例如，如果www.evil.example.com包含托管在www.google.com上的脚本，则该脚本在邪恶的上下文中而不是在google上下文中运行。因此，该脚本中的所有用户数据都会“泄漏”。
我看不到这在实践中会带来什么样的安全问题。我了解XSS和XSRF，但是XSSI对我来说有点神秘。
任何人都可以草拟基于XSSI的漏洞吗？
谢谢
如果使用JSONP传输数据，通常会出现问题。考虑一个由域A组成的网站，该域从域B加载数据。用户必须通过站点A和B的身份验证，并且由于同源策略禁止较旧的浏览器直接与不同于当前页面的域（B）通信（一），开发人员决定使用JSONP。因此，站点A包含指向http://B/userdata.js的脚本，类似于：
displayMySecretData({"secret":"this is very secret", ...})
因此，A定义了一个名为displayMySecretData的函数，并且当服务器B中包含的脚本运行时，它将调用该函数并将秘密数据显示给用户。
现在邪恶的服务器E出现了。它看到A使用JSONP包含了B的数据。因此，服务器E包含相同的脚本，但是定义了自己的displayMySecretData，而是窃取了数据。然后，攻击者诱骗用户访问他的站点。当用户去那里并登录到B时，浏览器会自动发送B的身份验证cookie以及从B提取脚本的请求。B看到经过身份验证的用户，因此按预期返回脚本。 E获取数据，并保存...
因此，使用JSONP从其他域加载机密数据确实不安全，但是人们仍在使用它。好主意！
XSSI不限于jsonp响应。在某些浏览器中，您可以覆盖Array构造函数。如果Json响应包含[...]，并且将其包含为脚本，它将执行新的构造函数，而不是内置的构造函数。解决方法是在响应中插入无法解析的内容，例如])}while(1);</x>，然后在解析之前使用代码将其删除。攻击者无法做到这一点，因为脚本包含始终是整个脚本。
http://google-gruyere.appspot.com/part3#3__cross_site_script_inclusion上有关此问题和此解决方案的更多详细信息>
XSSI是一种怪异的说法：您在程序中包含其他人的代码；您无法控制该代码中的内容，也无法控制托管该代码的服务器的安全性。