JSONP

Browsers and web ap­pli­ca­tions have many features and mech­a­nisms to protect users and their data from cyber-attacks. One of them is the same-origin policy, in short SOP, in­tro­duced by the former browser cor­po­ra­tion Netscape in 1996 upon the im­ple­men­ta­tion of JavaScript. This directive prohibits client-side scripting languages like JavaScript and Ac­tion­Script, but also stylesheet languages such as CSS, from accessing objects (graphics, videos, etc.) orig­i­nat­ing from another website or URL.

However, the bound­aries set by the same-origin policy are not ben­e­fi­cial for every type of web project, and can even be ob­struc­tive in certain cases – such as in web ap­pli­ca­tions that rely on an asyn­chro­nous data trans­mis­sion between the browser and server (for example, on an Ajax basis). For such projects, solutions to cir­cum­vent the directive, like the JSON method JSONP, are required. This is explained in more detail in the following sections.

JSONP (also written as JSON-P) is a method that helps struc­tured data be sent between different domains in JSON format. The acronym stands for JSON (JavaScript Object Notation) with Padding. To bypass the same-origin policy when re­quest­ing files from other domains, JSONP does not use the “XML­HttpRe­quest” object, as the usual JSON code does, but rather the element “script” including a function call. Unlike other files, scripts can also be trans­ferred across domains without the SOP being violated.

JSONP was developed in 2005 by software developer Bob Ippolito and has been in­te­grat­ed into many Web 2.0 frame­works such as Dojo Toolkit, jQuery, or Google Web Toolkit in recent years as a viable al­ter­na­tive to the customary JSON.

JSONP solves the same-origin policy problem using <script> elements. As many domains as you like can be specified in the “src” attribute of this element, and the directive does not apply here. Therefore, the attribute can also be used to dis­tin­guish URLs that belong to a foreign domain and return JSON code and other files. In such a case, the script itself is ex­clu­sive­ly used as a service provider, which sends the JSONP query to the re­spec­tive web server without having its own effect. In order for the client to be able to sub­se­quent­ly process the data, the server packs this again as a parameter in a JavaScript function, which is already pre­de­fined in the web browser and is com­mu­ni­cat­ed to the server in the query string (or query part) of the URL.

The following example is intended to clarify the operation of JSONP:

If this simple JSONP script is embedded in the HTML code of a website and then run by any client, JSON data is accessed by the foreign domain “not-origin-url.com” (“getjson”). The query string “?jsonp=ex­am­ple­Call­back” tells the contacted server that it is a JSONP query. In addition, the in­for­ma­tion is supplied that it should send the requested data as a parameter of the JavaScript function “ex­am­ple­Call­back”.

The server then generates the ap­pro­pri­ate JavaScript code including the queried in­for­ma­tion as a parameter – in the case of this example, a name-value pair – and returns it to the client:

The function call is then executed by the browser as if it were listed directly in the HTML code of the source page. The browser is thereby able to process the data retrieved from the third-party URL.

The following YouTube tutorial provides a slightly more extensive demon­stra­tion of the JSONP method:

JSONP is a solution for bypassing the SOP that is hotly debated in pro­fes­sion­al circles, due in par­tic­u­lar to the increased security risk as­so­ci­at­ed with script queries. This height­ened risk already arises by the fact alone that an ad­di­tion­al component is in­te­grat­ed into the processes of the website of origin, whose security system cannot be in­flu­enced. If, in fact, the contacted server exhibits vul­ner­a­bil­i­ties that enable unwanted JavaScript in­jec­tions (in­cor­po­ra­tion of JavaScript code) by attackers, the server of origin is au­to­mat­i­cal­ly exposed to an immediate danger – es­pe­cial­ly because not only JSON documents (as in the example), but any type of data can be retrieved.

Other known attack patterns that exploit the JSONP method are the following:

• RFD (Reflected File Download): JSONP is prone to RFD attacks, where client users only seemingly download data from the desired target domain. In fact, however, malicious files or URLs are loaded, which in most cases is due to ma­nip­u­la­tion of callback functions.

• CSRF/XSRF (Cross-Site Request Forgery): As the <script> element ignores the same-origin policy, a malicious website can request, obtain, and evaluate data from other web ap­pli­ca­tions. If the user is logged on to the attacked site, attackers with these “fake” cross-domain requests could access sensitive data such as login in­for­ma­tion.

  So, if you want to use JSONP scripts in your own web project, you should be ab­solute­ly sure that not only your own web server, but also the web server of the contacted web ap­pli­ca­tion is protected against such attacks and any kind of malware. JSONP code that retrieves data from insecure sources should therefore not be embedded or permitted.