What is Cross Site Script Inclusion (XSSI)?

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:

displayMySecretData({"secret":"this is very secret", ...})

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 displayMySecretData which 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 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 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

<script type="text/javascript" src="http://mymatedave.com/js/coolwidget.js"></script>

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.