14.07.2013 Views

Essentials of Javascript - Cultural View

Essentials of Javascript - Cultural View

Essentials of Javascript - Cultural View

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

JSON 104<br />

parseResponse({"Name": "Cheeso", "Rank": 7})<br />

...which can cause a change <strong>of</strong> state within the browser's execution context, because it invokes a method.<br />

The Padding<br />

While the padding (prefix) is typically the name <strong>of</strong> a callback function that is defined within the execution context <strong>of</strong><br />

the browser, it may also be a variable assignment, an if statement, or any other <strong>Javascript</strong> statement prefix.<br />

Script Tag Injection<br />

But to make a JSONP call, you need a script tag. Therefore, for each new JSONP request, the browser must add a<br />

new tag -- in other words, inject the tag -- into the HTML DOM, with the desired value for the src attribute.<br />

This element is then evaluated, the src URL is retrieved, and the response JSON is evaluated.<br />

In that way, the use <strong>of</strong> JSONP can be said to allow browser pages to work around the same origin policy via script<br />

tag injection.<br />

Basic Security concerns<br />

Because JSONP makes use <strong>of</strong> script tags, calls are essentially open to the world. For that reason, JSONP may be<br />

inappropriate for carrying sensitive data. [24]<br />

Including script tags from remote sites allows the remote sites to inject any content into a website. If the remote sites<br />

have vulnerabilities that allow JavaScript injection, the original site can also be affected.<br />

Cross-site request forgery<br />

Naïve deployments <strong>of</strong> JSONP are subject to cross-site request forgery attacks (CSRF or XSRF). [25] Because the<br />

HTML tag does not respect the same origin policy in web browser implementations, a malicious page can<br />

request and obtain JSON data belonging to another site. This will allow the JSON-encoded data to be evaluated in<br />

the context <strong>of</strong> the malicious page, possibly divulging passwords or other sensitive data if the user is currently logged<br />

into the other site.<br />

This is only a problem if the JSON-encoded data contains sensitive information that should not be disclosed to a<br />

third party, and the server depends on the browser's Same Origin Policy to block the delivery <strong>of</strong> the data in the case<br />

<strong>of</strong> an improper request. There is no problem if the server determines the propriety <strong>of</strong> the request itself, only putting<br />

the data on the wire if the request is proper. Cookies are not by themselves adequate for determining if a request was<br />

authorized. Exclusive use <strong>of</strong> cookies is subject to cross-site request forgery.<br />

History<br />

The original proposal for JSONP appears to have been made by Bob Ippolito in 2005 [26] and is now used by many<br />

Web 2.0 applications such as Dojo Toolkit Applications, Google Web Toolkit Applications [27] and Web Services.<br />

Further extensions <strong>of</strong> this protocol have been proposed by considering additional input arguments as, for example, is<br />

the case <strong>of</strong> JSONPP [28] supported by S3DB web services.<br />

Object references<br />

The JSON standard does not support object references, but the Dojo Toolkit illustrates how conventions can be<br />

adopted to support such references using standard JSON. Specifically, the dojox.json.ref [29] module provides<br />

support for several forms <strong>of</strong> referencing including circular, multiple, inter-message, and lazy referencing. [30]

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!