Difference between XSSI and XSS/CSRF

During an XSS malicious code is placed into a victim’s page, during an XSSI victim’s code is included in a malicious page. On the surface XSSI and CSRF look similar, because in both a request is sent from a malicious page to a different domain and in both cases the request is executed in the context of the logged in user. The key difference is the goal. In a CSRF, the attacker wants to execute state-changing actions inside a victim’s page, like transferring money in an online banking application. In an XSSI the attacker wants to leak data cross-origin, in order to then execute one of the aforementioned attacks.

More ref at https://www.scip.ch/en/?labs.20160414

Generally devs use JSONP (see below) to bypass SOP and include resources from esternal sites.

What is JSONP? or JSON with Padding

  • JSONP is a method for sending JSON data without worrying about cross-domain issues.
  • JSONP does not use the XMLHttpRequest object.
  • JSONP uses the

Server Example:

$myJSON = '{ "name":"John", "age":30, "city":"New York" }';

echo "myFunc(".$myJSON.");";

This will return: myFunc({ “name”:”John”, “age”:30, “city”:”New York” });

This could be included in a dynamically created script tag:

function clickButton() {
    var s = document.createElement("script");
    s.src = "demo_jsonp.php";

And, having a function called myFunc already defined client-side, this will execute the server instruction in the client browser.

So what is XSSI

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 fecth the script from B. B sees an authenticated user, and thus returns the script as expected. E gets the data, and presto…

How to exploit XSSI ?

Often scripts included can contains sensitive information in the global variables, allowing an attacker to potentially read all the secret data.

Some scripts (when requested with cookie, and so the user is authenticated) reply with a different code than when a user make the same request without cookie aside (un-authenticated).



  • Reading variables
  • Overriding functions
    1. If sensitive content is directly put into the web page global variables, one method to retrieve that data is simply to ask for it.


`<script src="[https://www.vulnerable-domain.tld/script.js](https://www.vulnerable-domain.tld/script.js)"></script>`

has a variable like:

keys = [ domain: 'live.com', apiKey: 'dsd2kgijland3io1', privkey:' *rsa key*', ... ]

Then an attacker could just inject an


to retrieve all the secrets.

  1. Override a function which could display user data using JSONP callback.


If the attacker can OVERRIDE a javascript function then he can read all the data returned by an external source (possibly with authenticated content)!!

So for example if Angular JS does have a function like this which handle sensitive information:


then an attacker could inject:

          var angular = function () { return 1; };
          angular.callbacks = function () { return 1; };      
          angular.callbacks._7 = function (leaked) {

Before the inclusion of the external script.

We could suppose the server is dynamically generating javascript code. How does he know which function to use? We could suppose this is passeb by GET requests?

For example if the function needed is myFunc then the script will be:

`<script src="https://site.tld/p?jsonp=myFunc" type="text/javascript"></script>`

The function myFunc will be used as callback as soon as data is returned.

What if an attacker can change the requesting callback and then writes his own in the victim browser? like this?

      leak = function (leaked) {
<script src="https://site.tld/p?jsonp=leak" type="text/javascript"></script>


Never put sensitive content on Javascript and JSONP.

Instruct the browser not to guess the Content-Type with:

X-Content-Type-Options: nosniff

A correct Content-Type is also helpful in reducing the chance of XSSI.

Please feel free to make any comment! If anything is unclear, just write in the comment and I will update the post!Thanks for reading!