JSONP

Browsers and web ap­plic­a­tions have many features and mech­an­isms 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­por­a­tion Netscape in 1996 upon the im­ple­ment­a­tion of JavaS­cript. This directive prohibits client-side scripting languages like JavaS­cript and Ac­tion­Script, but also stylesheet languages such as CSS, from accessing objects (graphics, videos, etc.) ori­gin­at­ing from another website or URL.

However, the bound­ar­ies set by the same-origin policy are not be­ne­fi­cial for every type of web project, and can even be ob­struct­ive in certain cases – such as in web ap­plic­a­tions that rely on an asyn­chron­ous 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 “XM­L­Ht­tpRe­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­teg­rated into many Web 2.0 frame­works such as Dojo Toolkit, jQuery, or Google Web Toolkit in recent years as a viable al­tern­at­ive 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­clus­ively used as a service provider, which sends the JSONP query to the re­spect­ive web server without having its own effect. In order for the client to be able to sub­sequently process the data, the server packs this again as a parameter in a JavaS­cript function, which is already pre­defined in the web browser and is com­mu­nic­ated 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­ample­Call­back” tells the contacted server that it is a JSONP query. In addition, the in­form­a­tion is supplied that it should send the requested data as a parameter of the JavaS­cript function “ex­ample­Call­back”.

The server then generates the ap­pro­pri­ate JavaS­cript code including the queried in­form­a­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­ated with script queries. This heightened risk already arises by the fact alone that an ad­di­tion­al component is in­teg­rated 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­ab­il­it­ies that enable unwanted JavaS­cript in­jec­tions (in­cor­por­a­tion of JavaS­cript code) by attackers, the server of origin is auto­mat­ic­ally exposed to an immediate danger – es­pe­cially 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­plic­a­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­form­a­tion.

  So, if you want to use JSONP scripts in your own web project, you should be ab­so­lutely sure that not only your own web server, but also the web server of the contacted web ap­plic­a­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.