什么是跨站脚本包含 (XSSI)？
我最近在多个页面上看到了 XSSI 的提及，例如 Web 应用程序利用和防御：
浏览器阻止一个域的页面读取其他域中的页面。但它们不会阻止域的页面引用其他域中的资源。特别是，它们允许从其他域渲染图像并从其他域执行脚本。包含的脚本没有自己的安全上下文。它在包含它的页面的安全上下文中运行。例如，如果 www.evil.example.com 包含 www.google.com 上托管的脚本，则该脚本在恶意上下文中运行，而不是在 google 上下文中运行。因此该脚本中的任何用户数据都会“泄漏”。
我看不出这在实践中会产生什么样的安全问题。我了解 XSS 和 XSRF，但 XSSI 对我来说有点神秘。
有人可以绘制一个基于 XSSI 的漏洞利用程序吗？
谢谢
I've recently seen XSSI mentioned on multiple pages, e.g. Web Application Exploits and Defenses:
Browsers prevent pages of one domain from reading pages in other domains. But they do not prevent pages of a domain from referencing resources in other domains. In particular, they allow images to be rendered from other domains and scripts to be executed from other domains. An included script doesn't have its own security context. It runs in the security context of the page that included it. For example, if www.evil.example.com includes a script hosted on www.google.com then that script runs in the evil context not in the google context. So any user data in that script will "leak."
I fail to see what kind of security problems this creates in practice. I understand XSS and XSRF but XSSI is a little mysterious to me.
Can anybody sketch an exploit based on XSSI?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您使用 JSONP 传输数据，这通常是一个问题。考虑一个由域 A 组成的网站，该域从域 B 加载数据。用户必须通过站点 A 和 B 的身份验证，并且因为同源策略会阻止较旧的浏览器直接与与当前页面不同的域 (B) 进行通信(A)、开发人员决定使用 JSONP。因此，站点 A 包含一个指向 http://B/userdata.js 的脚本，如下所示：
所以 A 定义一个名为
displayMySecretData的函数，当服务器 B 中包含的脚本运行时，它会调用该函数并向用户显示秘密数据。现在邪恶的服务器E出现了。它看到 A 使用 JSONP 包含来自 B 的数据。因此服务器 E 包含相同的脚本，但定义了自己的
displayMySecretData来窃取数据。然后，攻击者诱骗用户访问他的网站。当用户到达那里并登录到 B 时，浏览器会自动发送 B 的身份验证 cookie 以及从 B 获取脚本的请求。B 看到经过身份验证的用户，因此按预期返回脚本。 E 获取数据，然后...
使用 JSONP 从不同域加载机密数据，这种方式确实不安全，但人们仍在使用它。坏主意！
This is typically a problem if you are using JSONP to transfer data. Consider a website consisting of a domain A that loads data from domain B. The user has to be authenticated to site A and B, and because the Same Origin Policy prevents older browsers from communicating directly with a different domain (B) than the current page (A), the developers decided to use JSONP. So site A includes a script pointing to http://B/userdata.js which is something like:
So A defines a function called
displayMySecretData, and when the included script from server B runs, it calls that function and displays the secret data to the user.Now evil server E comes along. It sees that A is including data from B using JSONP. So server E includes the same script, but defines its own
displayMySecretDatawhich instead steals the data.The attacker then tricks the user into visiting his site. When the user goes there and he is logged in to B, the browser automatically sends the authentication cookies for B along with the request to fetch the script from B. B sees an authenticated user, and thus returns the script as expected. E gets the data, and presto...
Using JSONP to load confidential data from a different domain this way is thus really insecure, but people are still using it. Bad idea!
XSSI 不仅限于 jsonp 响应。在某些浏览器中，您可以覆盖 Array 构造函数。如果 Json 响应包含
[...]并且您将其作为脚本包含在内，它将执行新的构造函数而不是内置构造函数。解决方法是在响应中插入无法解析的内容，例如])}while(1);，然后在解析之前使用代码将其删除。攻击者无法这样做，因为脚本包含始终是整个脚本。有关该问题和此解决方案的更多详细信息，请访问 http://google-gruyere.appspot.com/part3# 3__cross_site_script_inclusion
XSSI is not limited to jsonp responses. In some browsers you can override the Array constructor. If a Json response contains
[...]and you include it as a script it will execute the new constructor instead of the builtin one. The fix is to insert something in the response that can't be parsed like])}while(1);</x>and then use code to remove it before parsing it. An attacker can't do that since script inclusion is always the entire script.More detail on the problem and this solution at http://google-gruyere.appspot.com/part3#3__cross_site_script_inclusion
XSSI 是一种奇特的表达方式：您在自己的程序中包含了其他人的代码；您无法控制该代码中的内容，也无法控制托管该代码的服务器的安全性。
例如，假设我在 html 页面中包含
该脚本，该脚本将在我的 web 应用程序中运行，其信任级别与我自己的任何 javascript 代码相同。它将能够访问整个页面内容和 DOM，它将能够读取我的所有应用程序的 cookie 并读取用户的按键和鼠标移动，以及 javascript 可以执行的所有其他操作。
如果我的朋友戴夫决定在他很酷的小部件中放置一些恶意内容（例如，将所有用户的 cookie、表单数据和按键发送到他的服务器的嗅探器/键盘记录器），那么我不一定知道。另外，我的应用程序的安全性现在取决于戴夫服务器的安全性。如果 Dave 的服务器遭到破坏并且 Coolwidget.js 被攻击者替换，我也不一定知道，恶意代码将作为我的应用程序的一部分运行。
XSSI is a fancy way of saying: you are including in your program, someone elses code; You don't have any control over what is in that code, and you don't have any control over the security of the server on which it is hosted.
For example, let's say i include in my html page
That script will run in my webapp with the same level of trust as any of my own javascript code. It will have access to the the full page content and DOM, it will be able to read all my app's cookies and read the users keypresses and mouse movements, and everything else that javascript can do.
If my mate dave, then decides to put something malicious in his cool widget (say, a sniffer/keylogger that sends all the user's cookies, form data and keypresses to his server) then I won't necessarily know. Also, the security of my app now depends on the security of dave's server. If dave's server gets compromised and coolwidget.js is replaced by the attacker, i again won't necessarily know and the malicious code will run as part of my app.